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. 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. >>>> >> >>
