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ò <[email protected]> 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ò <[email protected]> >> 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/ >
