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