Am 09.04.2014 um 19:31 schrieb Tobias Bocanegra <tri...@apache.org>:
> oh another use case: login with case-insensitive user id. > > this is similar in that respect, that the 'id' in the credentials used > to login, is not (or must not be) identical to the userid of the > resolved authorizable. > but the question is, where would this be configured? on all login modules? This is also LoginModule specific IMHO Regards Felix > > regards, toby > > On Wed, Apr 9, 2014 at 12:14 AM, Felix Meschberger <fmesc...@adobe.com> wrote: >> Hi >> >> Am 09.04.2014 um 09:09 schrieb Tobias Bocanegra <tri...@apache.org>: >> >>>>> 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 ? >>> >>> well, I think then the authenticator should use different credentials. >> >> If the user provides user name and password ? Absolutely not. If the user is >> presenting user name, password and some 3rd party OTP or such, absolutely. >> >> Interpreting the provided user name ? Probably not. That's not the business >> of the authentication handler, since to the handler the user name is an >> opaque string of characters. >> >>> however, mapping the DN to as userid would be job of the login module. >>> i.e. provide the userid for session.getUserId() and populate the >>> subject with the correct principals. >> >> As is mapping the domain/user name to a userid. Same game. >> >>> >>>> 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. >>> >>> yes, but we (currently) have 3 login modules: default, token, external >>> (and adobe granite has SSO). >>> all of them would need to handle the windows domain (well, maybe not >>> the token lm). >> >> Probably not. I would think LoginModules can or cannot handle. If one module >> cannot handle, it cannot authenticate. Depending on how the module is >> configured into the system (required or sufficient), login may succeed or >> not. >> >> Regards >> Felix >> >>> >>> regards, toby >>> >>>> >>>> Regards >>>> Felix >>>> >>>>> >>>>> regards, toby >>>>> >>>>>> >>>>>> Just my $.02. >>>>>> >>>>>> Regards >>>>>> Felix >>>>>> >>>>>> Am 08.04.2014 um 09:15 schrieb Angela Schreiber <anch...@adobe.com>: >>>>>> >>>>>>> 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" <tri...@apache.org> 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 >>>>>>> >>>>>> >>>> >>
