jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Login with userid that contains windows domain
Date Tue, 08 Apr 2014 07:15:04 GMT
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" <tripod@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


Mime
View raw message