You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Tobias Bocanegra <tr...@apache.org> on 2014/04/07 20:26:18 UTC
Login with userid that contains windows domain
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
Re: Login with userid that contains windows domain
Posted by Felix Meschberger <fm...@adobe.com>.
Am 09.04.2014 um 19:31 schrieb Tobias Bocanegra <tr...@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 <fm...@adobe.com> wrote:
>> Hi
>>
>> Am 09.04.2014 um 09:09 schrieb Tobias Bocanegra <tr...@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 <an...@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" <tr...@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
>>>>>>>
>>>>>>
>>>>
>>
Re: Login with userid that contains windows domain
Posted by Tobias Bocanegra <tr...@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?
regards, toby
On Wed, Apr 9, 2014 at 12:14 AM, Felix Meschberger <fm...@adobe.com> wrote:
> Hi
>
> Am 09.04.2014 um 09:09 schrieb Tobias Bocanegra <tr...@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 <an...@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" <tr...@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
>>>>>>
>>>>>
>>>
>
Re: Login with userid that contains windows domain
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 09.04.2014 um 09:09 schrieb Tobias Bocanegra <tr...@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 <an...@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" <tr...@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
>>>>>
>>>>
>>
Re: Login with userid that contains windows domain
Posted by Tobias Bocanegra <tr...@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.
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.
> 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).
regards, toby
>
> Regards
> Felix
>
>>
>> regards, toby
>>
>>>
>>> Just my $.02.
>>>
>>> Regards
>>> Felix
>>>
>>> Am 08.04.2014 um 09:15 schrieb Angela Schreiber <an...@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" <tr...@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
>>>>
>>>
>
Re: Login with userid that contains windows domain
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 08.04.2014 um 19:18 schrieb Tobias Bocanegra <tr...@apache.org>:
> On Tue, Apr 8, 2014 at 8:09 AM, Felix Meschberger <fm...@adobe.com> 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 <an...@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" <tr...@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
>>>
>>
Re: Login with userid that contains windows domain
Posted by Tobias Bocanegra <tr...@apache.org>.
On Tue, Apr 8, 2014 at 8:09 AM, Felix Meschberger <fm...@adobe.com> 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 <an...@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" <tr...@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
>>
>
Re: Login with userid that contains windows domain
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Apr 8, 2014 at 11:09 AM, Felix Meschberger <fm...@adobe.com> wrote:
> If the domain in the user name should be handled with significance, this should
> be done by the LoginModule assuming significance.
+1, I would expect such details to remain hidden within the
authentication components.
BR,
Jukka Zitting
Re: Login with userid that contains windows domain
Posted by Felix Meschberger <fm...@adobe.com>.
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 …
If the domain in the user name should be handled with significance, this should be done by the LoginModule assuming significance.
Just my $.02.
Regards
Felix
Am 08.04.2014 um 09:15 schrieb Angela Schreiber <an...@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" <tr...@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
>
Re: Login with userid that contains windows domain
Posted by Angela Schreiber <an...@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" <tr...@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