incubator-syncope-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordi Clement <jclem...@dds.nl>
Subject Re: "Virtual" resources - resources not tied to an actual application or system account
Date Mon, 22 Oct 2012 09:23:51 GMT
Hi.

all clear. I'll try to configure a "virtual resource" using the method suggested and report
back. But what if we would implement this ourselves? How would we go about this? Decide on
the implementation strategy over the mailing list, make the change and than handover a patch
for someone to commit? Can we get someone from our team to commit code? Should this be discussed
over the developers mailing list? We maybe have some other (minor) stuff worth committing.


regards,

Jordi
  
On 22 okt. 2012, at 11:14, Francesco Chicchiriccò <ilgrosso@apache.org> wrote:

> On 22/10/2012 10:21, Jordi Clement wrote:
>> Hi, 
>> 
>> please find my reply inline. 
>> 
>> On 17 okt. 2012, at 13:21, Francesco Chicchiriccò <ilgrosso@apache.org> wrote:
>>> On 17/10/2012 13:09, Jordi Clement wrote:
>>>> Hi everyone,
>>>> 
>>>> Syncope currently does not provide something like "virtual resources", i.e.
every resource is related to a connector and a target system / application. Virtual resources
on the other hand can basically be anything, for instance a mobile phone or hardware token
you'd like to "provision" to the user and include in your workflow and that you want to manage
through the user's identity lifecycle. 
>>>> 
>>>> I've implemented provisioning solutions in the past that supported these
"virtual" resources and it's something that, if available, we would put to good use right
away. 
>>>> 
>>>> What do you guys think? Would that be a good addition to Syncope's functionality?

>>> Hi Jordi,
>>> this sounds very interesting: you are basically proposing to have 'empty' resources
- i.e. external resources without an associated connector instance - to be used like as 'marker'
for users and / or
>>> roles. Correct?
>> Yes, this is correct. 
>> 
>>> If so, this could also be in the direction of SYNCOPE-167 [1].
>> I don't understand the functionality suggested in SYNCOPE-167. Can you please elaborate
on that one? Maybe explain in the form of typical use case / scenario?
> 
> SYNCOPE-167 (as SYNCOPE-166 and SYNCOPE-160) is part of a general
> feature extension planning to add access management features in Syncope
> - quite far in the roadmap, currently.
> 
> Basically, SYNCOPE-167 is about defining, for example, an URL resource
> with associated capabilities that can be granted to a role under some
> conditions (date/time, ...). This would make an access policy.
> 
>>>> And is there a way we could simulate such a resource now (for instance, using
an "empty" connector that we could tie to these virtual resources?).
>>> The closest match to what you describe above would be to define a connector instance
(of *any* connector bundle) with no capabilities, then create an external resource with such
connector instance.
>> This is only configuration, and no development is necessary. Do I understand correctly?
I'll give it a go to decide whether we can use this mechanism for the time being.
> 
> Correct: you can do this just by configuration.
> 
>>> You will, though, get some "noise" in the logs (see error message at [2]).
>> I've taken a look at this page, but I'm not sure what your referring to on that page?
That last log message I guess?
> 
> Exactly.
> 
> Regards.
> 
>> [1] https://issues.apache.org/jira/browse/SYNCOPE-167
>> [2] https://cwiki.apache.org/confluence/display/SYNCOPE/Propagation+mode#Propagationmode-Operationalsideeffectsofconfigurationinconsistencies
> 
> -- 
> Francesco Chicchiriccò
> 
> ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
> 


Mime
View raw message