Hi Am 08.04.2014 um 19:18 schrieb Tobias Bocanegra <[email protected]>:
> On Tue, Apr 8, 2014 at 8:09 AM, Felix Meschberger <[email protected]> wrote: >> Hi >> >> With my Sling hat on: Toby's variant 2 (JCR Client, e.g. Sling >> AuthenticationHandler, should do the work) sounds wrong to me. Because for >> Sling, this is just an opaque user name and there is no reason, why the >> generic JCR client should interpret it in any way - after all the JCR client >> deals with JCR and nothing else. Else others could come around and claim >> other interpretations and special casing … > > well, it's not quite so simple. for other kind of credentials, the > client that calls repository.login() constructs the correct > credentials that can be used by a login module. but there might be > more information available to pass along, e.g. a security token. in > those cases, you wouldn't rely on the login module solely. > > IMO, the DOMAIN\userid is (was) just a simple way for windows to > extend their login chain with domain information. > > also, what do you expect from: > repository.login(creds_with_domain_in_userid).getUserId() ? surely the > userid w/o domain. Well, I would expect Session.getUserId to return the same as I provided in the Credentials. But then, the API states, that this is not necessairily the case. > >> If the domain in the user name should be handled with significance, this >> should be done by the LoginModule assuming significance. > it all boils down to the problem of credentials to userid mapping. and > the simple credentials clearly state that they contain a password and > a userid (and not a login id, or windows domain+userid, or ldap DN, or > email address). > > we could solve this transparently for all login modules that extend > from AbstractLoginModule with a general processCredentials() method > that extracts the userid and/or domain specifier. but I would favor a > more general credentials -> userid mapping. for example to support the > use case to login with an email address but having a different userid. So you propose special casing for the windows domain mechanism. What if users login with an absolute LDAP/X.500 DN ? Would you extend the special casing to support extracting the CN ? What if the CN is not the actual user ID ? The whole point of having LoginModule is to have this transparent and extensible. You don't want to code special cases in a common abstract base class again. Regards Felix > > regards, toby > >> >> Just my $.02. >> >> Regards >> Felix >> >> Am 08.04.2014 um 09:15 schrieb Angela Schreiber <[email protected]>: >> >>> hoi >>> >>> variant 2 only works if you just have a single IdentityProvider >>> configured with your external login module, right? >>> >>> based on how we deal with these situations otherwise in Oak and in >>> particular in the security area, i would feel more comfortable if we >>> at some point had the ability to support multiple IdentityProvider >>> implementations. >>> in particular since the external login module is no longer specific >>> for a particular backend but very generic and just uses the configured >>> IdentityProvider to perform the JAAS login. >>> >>> IMO are different ways on how to achieve this: if we thing of having >>> 2 identity provider implementations we could either have 2 entries in >>> the JAAS config listing the ExternalLoginModule with different >>> configuration (i.e. IdentityProvider implementation) or we had 1 single >>> entry but a composing IdentityProvider that manages both identity >>> providers. >>> >>> for either possibility the domain information would be needed in the >>> login module and i see the following possibility to get this: >>> >>> A. define an attribute on the SimpleCredentials that contains the domain. >>> B. define a dedicated Credentials interface extending from >>> SimpleCredentials >>> which specifically allows to obtain the domain information. >>> C. the domain is part of the userId exposed by SimpleCredentials and >>> extracted during the login call only (this is your variant 1). >>> >>> from my point of view 1/C looks a quite troublesome as it requires to >>> add some magic to the userId, which is properly understood and handled >>> by a single login module only (assuming that we would not want the >>> domain to be stored as part of the userID of the synchronized user). >>> >>> A/B would be compatible with your proposal 2 below without loosing the >>> domain information... i have slight preference for B as it would allow >>> to separate the domain information from other credentials attributes. >>> since the ExternalLoginModule could handle both SimpleCredentials >>> without domain information attribute as you suggested) and the >>> new domain-SimpleCredentials, we can easily enhance the >>> SSOAuthenticationHandler >>> and ExternalLoginModule after 1.0 to fully support different >>> domains/IdentityProviders >>> during repository login. >>> >>> would that make sense to you? >>> >>> kind regards >>> angela >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 07/04/14 20:26, "Tobias Bocanegra" <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I have an issue where the user tries to login using credentials that >>>> include a windows domain in the userid attribute. for example: >>>> "MYDOMAIN\toby". >>>> >>>> I'm not sure which layer should handle the domain part correctly, and >>>> I think it really depends on the setup. also, I'm not an AD expert and >>>> I don't know how the domain part would be used (selecting a "forest" >>>> in the AD server? or selecting a different AD server?). >>>> >>>> the problem especially comes up in SSO situations, where the >>>> LOGON_USER is passed over to a web application (e.g. sling) that then >>>> uses the repository. >>>> >>>> I can imagine the following scenarios: >>>> >>>> a) domain is constant/does not apply/or is a leftover from the SSO. so >>>> the repository does not (and never will) know about domains. >>>> >>>> b) domain is part of the userid, i.e. effectively selects a different >>>> user, but the same AD is used for all external accounts >>>> >>>> c) domain is part of the userid, but the domain also selects different >>>> ADs. >>>> >>>> Right now, the external login module does not handle the domain >>>> specifier specifically, so would behave like (b) - although I think >>>> that the user would not be found on the AD via LDAP the way it is >>>> currently built. >>>> >>>> Also, for a simple SSO setup, where the authentication module of the >>>> web app retrieves the LOGON_USER, I think the domain should be >>>> stripped there and not being included in the jcr credentials. >>>> >>>> so this basically boils down to the question: >>>> >>>> 1) should we implement special handling for windows domain specifiers >>>> in the login modules? >>>> 2) should we ignore windows domain and delegate this work to the JCR >>>> client? (e.g. the sling authentication handler should strip off the >>>> domain when building the jcr credentials) >>>> >>>> I think as long as the domain is not part of the user >>>> selection/authentication, we should do 2). >>>> >>>> WDYT? >>>> Regards, Toby >>> >>
