Hi, On 22.06.2010 15:46, Justin Edelson wrote: > On 6/22/10 9:21 AM, Felix Meschberger wrote: >> Hi Justin, >> >> On 22.06.2010 15:09, Justin Edelson wrote: >>> On 6/22/10 3:44 AM, Felix Meschberger wrote: >>>> Hi, >>>> >>>> Rather than automatically creating JCR users for OpenID users, I would >>>> support (and call this mechanism) self-registration. >>>> >>>> We can still use AX, SReg, and similar extensions to prefill user >>>> details (if available from the OpenID provider). But I would not create >>>> users automatically on the fly without user intervention and without >>>> adding prevention to automatically fill the user space. >>>> >>>> As such this issue sounds like a duplicate of SLING-1562. >>> >>> The use case I have in mind here is very different than SLING-1562 - it >>> is for environments where an OpenID IDP is used as an identity provider >>> for an organization. For example, imagine an organization which uses >>> Google Apps for Domains and wants a Sling application to authenticate >>> users against their Google Apps account. In these circumstances, OpenID >>> is essentially used exactly like a LDAP server (which is why I drew that >>> parallel) - ONLY users from a particular IDP are allowed access to the >>> application and IDP is the user data source of record. >>> >>> I'll need this type of functionality in any case. If it ends up being >>> too specific to put into Sling, I'll keep it out. What may be necessary >>> is to add the Listener whiteboard I suggested below, but I can create >>> another JIRA for that when it comes up. >> >> Thanks for the explanation. >> >> Sounds good, lets go ... ;-) >> >> Anyway, also for SLING-1562 would we need some hookup support from the >> OpenID handler to be able to query the OpenID provider for more details >> than just the identity. >> >> How about adding a service interface to the OpenID auth bundle, which >> allows for asking for more information of the currently logged in user >> (or any OpenID identity) without exposing DYU ? Would this be possible >> without making it too complex ? > Well, the advantage of using DYU's Listener is that they've already > implemented support for AX, SReg, OAuth, etc. I don't think we want to > end up in a situation where a bundle is wrapping DYU's OAuth Listener in > an implementation of our interface which then gets invoked by our > whiteboard which implements the DYU Listener interface. > > That said, I see where you're going with this and I agree that it would > be good to avoid exporting the implementation detail that we're using > DYU. I just don't know how to go about that.
Yes, this is the dilemma ... We could of course export (part of) the dyuproject-openid library and expose a properly configured RelyingParty object as a service. Regards Felix > > Justin > >> >> Regards >> Felix >> >>> >>> Thanks, >>> Justin >>> >>>> >>>> Regards >>>> Felix >>>> >>>> On 21.06.2010 15:36, Justin Edelson (JIRA) wrote: >>>>> Automatically create a User object for an OpenID identifier >>>>> ----------------------------------------------------------- >>>>> >>>>> Key: SLING-1563 >>>>> URL: https://issues.apache.org/jira/browse/SLING-1563 >>>>> Project: Sling >>>>> Issue Type: New Feature >>>>> Components: Extensions >>>>> Reporter: Justin Edelson >>>>> >>>>> >>>>> Similar to how CRX supports autocreating User accounts when a successful >>>>> LDAP authentication is done >>>>> (http://dev.day.com/docs/en/crx/current/administering/ldap_authentication.html#Auto >>>>> Creation), it would be nice if the OpenID authentication bundle could >>>>> support autocreate a user account under a certain set of circumstances. >>>>> >>>>> * This function should be *disabled* by default. >>>>> * Use AX (http://openid.net/specs/openid-attribute-exchange-1_0.html) to >>>>> request a set of user attributes from the identity provider and the >>>>> configurable mappings between these attributes and User node properties. >>>>> * Since OpenID doesn't support groups, a default set of one or more >>>>> groups needs to be specified for new users. >>>>> * A regex can be supplied for OpenID identifiers to limit which >>>>> identifiers will result in auto-generated User accounts >>>>> >>>>> I'm doubtful that this should be done in the openid auth bundle. An >>>>> alternative would be to create a whiteboard to look for implementations >>>>> of DYU's Listener interface. Newer DYU versions have AX support via a >>>>> Listener and I'm pretty sure the autocreation could be done in a Listener >>>>> as well. >>>>> >>> >>> > >
