[JBoss JIRA] (ELY-865) Principal name from realms should not be pure user input
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-865?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-865:
---------------------------
Priority: Critical (was: Major)
> Principal name from realms should not be pure user input
> --------------------------------------------------------
>
> Key: ELY-865
> URL: https://issues.jboss.org/browse/ELY-865
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> All security realm now provides user-provided username as realmIdentity principal.
> That can be problem, if identity search is case-insensitive - for example:
> * Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can be two different users for application running on AS
> * the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
> * the same can probably occure for JDBC, if database column is defined as case-insensitive
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-865) Principal name from realms should not be pure user input
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-865?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-865:
---------------------------
Description:
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive - for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can be two different users for application running on AS, which can be security problem
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
was:
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive - for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can be two different users for application running on AS
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
> Principal name from realms should not be pure user input
> --------------------------------------------------------
>
> Key: ELY-865
> URL: https://issues.jboss.org/browse/ELY-865
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> All security realm now provides user-provided username as realmIdentity principal.
> That can be problem, if identity search is case-insensitive - for example:
> * Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can be two different users for application running on AS, which can be security problem
> * the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
> * the same can probably occure for JDBC, if database column is defined as case-insensitive
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-865) Principal name from realms should not be pure user input
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-865?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-865:
---------------------------
Description:
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive - for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can act as two different users for application running on AS - it can be security problem
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
was:
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive - for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can be two different users for application running on AS, which can be security problem
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
> Principal name from realms should not be pure user input
> --------------------------------------------------------
>
> Key: ELY-865
> URL: https://issues.jboss.org/browse/ELY-865
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> All security realm now provides user-provided username as realmIdentity principal.
> That can be problem, if identity search is case-insensitive - for example:
> * Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can act as two different users for application running on AS - it can be security problem
> * the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
> * the same can probably occure for JDBC, if database column is defined as case-insensitive
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-865) Principal name from realms should not be pure user input
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-865?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-865:
---------------------------
Description:
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive - for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can be two different users for application running on AS
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
was:
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive - for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive, realm correctly found "firstUser" - but they will obtain two different NamePrincipal - the same user can be two different users for application running on AS
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
> Principal name from realms should not be pure user input
> --------------------------------------------------------
>
> Key: ELY-865
> URL: https://issues.jboss.org/browse/ELY-865
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> All security realm now provides user-provided username as realmIdentity principal.
> That can be problem, if identity search is case-insensitive - for example:
> * Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can be two different users for application running on AS
> * the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
> * the same can probably occure for JDBC, if database column is defined as case-insensitive
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-865) Principal name from realms should not be pure user input
by Jan Kalina (JIRA)
Jan Kalina created ELY-865:
------------------------------
Summary: Principal name from realms should not be pure user input
Key: ELY-865
URL: https://issues.jboss.org/browse/ELY-865
Project: WildFly Elytron
Issue Type: Bug
Reporter: Jan Kalina
Assignee: Jan Kalina
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive, realm correctly found "firstUser" - but they will obtain two different NamePrincipal - the same user can be two different users for application running on AS
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-865) Principal name from realms should not be pure user input
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-865?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-865:
---------------------------
Description:
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive - for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive, realm correctly found "firstUser" - but they will obtain two different NamePrincipal - the same user can be two different users for application running on AS
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
was:
All security realm now provides user-provided username as realmIdentity principal.
That can be problem, if identity search is case-insensitive for example:
* Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive, realm correctly found "firstUser" - but they will obtain two different NamePrincipal - the same user can be two different users for application running on AS
* the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
* the same can probably occure for JDBC, if database column is defined as case-insensitive
> Principal name from realms should not be pure user input
> --------------------------------------------------------
>
> Key: ELY-865
> URL: https://issues.jboss.org/browse/ELY-865
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> All security realm now provides user-provided username as realmIdentity principal.
> That can be problem, if identity search is case-insensitive - for example:
> * Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive, realm correctly found "firstUser" - but they will obtain two different NamePrincipal - the same user can be two different users for application running on AS
> * the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory
> * the same can probably occure for JDBC, if database column is defined as case-insensitive
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-857:
--------------------------------------
Overall it does seem like something is missing - the realm should have a final say in what the identity it returns look like.
> Elytron ldap-realm is not able to use LDAP attribute as principal
> -----------------------------------------------------------------
>
> Key: ELY-857
> URL: https://issues.jboss.org/browse/ELY-857
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> In Elytron ldap-realm is currently not possible to obtain username from LDAP attribute which is different than rdn-identifier. It means that username of identity is always the same as value of rdn-identifier attribute.
> It can cause issues when ldap-realm is used for authentication and another realm is used for authorization since data for realm authorization can depend on assigned name during authentication.
> Example:
> It seems that ldap-realm cannot be configured for following scenario: User with credentials {{someUser}}/{{Password}} is authenticated and name {{AuthenticatedUser}} is assigned to them (e.g. when calling {{./jboss-cli.sh -c -u=someUser -p=Password ':whoami'}}, then {{AuthenticatedUser}} should be printed). Following ldif is used:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: AuthenticatedUser
> userPassword: Password
> {code}
> Mentioned ldif works correctly with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-857:
--------------------------------
[~dlofthouse] I think this mapping cannot be done using current Principal transformers, as they are Function<Principal, Principal> only - they cannot access identity attributes. But for example simple attribute of domain, which would say, which identity attribute to consider to be a principal?
> Elytron ldap-realm is not able to use LDAP attribute as principal
> -----------------------------------------------------------------
>
> Key: ELY-857
> URL: https://issues.jboss.org/browse/ELY-857
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> In Elytron ldap-realm is currently not possible to obtain username from LDAP attribute which is different than rdn-identifier. It means that username of identity is always the same as value of rdn-identifier attribute.
> It can cause issues when ldap-realm is used for authentication and another realm is used for authorization since data for realm authorization can depend on assigned name during authentication.
> Example:
> It seems that ldap-realm cannot be configured for following scenario: User with credentials {{someUser}}/{{Password}} is authenticated and name {{AuthenticatedUser}} is assigned to them (e.g. when calling {{./jboss-cli.sh -c -u=someUser -p=Password ':whoami'}}, then {{AuthenticatedUser}} should be printed). Following ldif is used:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: AuthenticatedUser
> userPassword: Password
> {code}
> Mentioned ldif works correctly with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-857 at 1/10/17 1:47 PM:
---------------------------------------------------------
Not sure but mabe the problem can occure also in FileSystemRealm - if there is user "firstUser", user can log in successfully as "FIRSTUSER" on Windows too - so he can obtain two different principals - realm should normalize it, or better use user input only for search, but the principal obtain from database :(
This is reason, why I think this would be better to solve on higher level - outside of individual realms. Maybe could be this mapping on domain level? (configuration of domain would say, which identity attribute will be used as identity principal - but usable only for NamePrincipal)
was (Author: honza889):
Not sure but mabe the problem can occure also in FileSystemRealm - if there is user "firstUser", user can log in successfully as "FIRSTUSER" on Windows too - so he can obtain two different principals - realm should normalize it, or better use user input only for search, but the principal obtain from database :(
This is reason, why I think this would be better to solve on higher level - outside of individual realms.
> Elytron ldap-realm is not able to use LDAP attribute as principal
> -----------------------------------------------------------------
>
> Key: ELY-857
> URL: https://issues.jboss.org/browse/ELY-857
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> In Elytron ldap-realm is currently not possible to obtain username from LDAP attribute which is different than rdn-identifier. It means that username of identity is always the same as value of rdn-identifier attribute.
> It can cause issues when ldap-realm is used for authentication and another realm is used for authorization since data for realm authorization can depend on assigned name during authentication.
> Example:
> It seems that ldap-realm cannot be configured for following scenario: User with credentials {{someUser}}/{{Password}} is authenticated and name {{AuthenticatedUser}} is assigned to them (e.g. when calling {{./jboss-cli.sh -c -u=someUser -p=Password ':whoami'}}, then {{AuthenticatedUser}} should be printed). Following ldif is used:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: AuthenticatedUser
> userPassword: Password
> {code}
> Mentioned ldif works correctly with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is not able to use LDAP attribute as principal
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-857 at 1/10/17 1:45 PM:
---------------------------------------------------------
Notes: result of WhoAmIOperation is obtained as:
{code:java}securityIdentity.getPrincipal().getName(){code}
The principal is really output of realm: (see ServerAuthenticationContext class)
{code:java}principal = getSecurityRealm().getRealmIdentity(evidence).getRealmIdentityPrincipal(){code}
But in LdapRealm (and FileSystem and Jdbc too) it is currently hardcoded as username - input of the realm.
*Possible solution:*
a) add mapping from identity attribute to identity principal into LdapRealm (add "username-attribute into ldap-realm and map this identity attribute to NamePrincipal when defined)
b) to use identity attribute instead of special method for principal to add this possibility into all realms at once?
[~dlofthouse] do you think this should be solved for LDAP only, or on higher level?
was (Author: honza889):
Notes: result of WhoAmIOperation is obtained as:
{code:java}securityIdentity.getPrincipal().getName(){code}
The principal is really output of realm: (see ServerAuthenticationContext class)
{code:java}principal = getSecurityRealm().getRealmIdentity(evidence).getRealmIdentityPrincipal(){code}
But in LdapRealm (and FileSystem and Jdbc too) it is currently hardcoded as username - input of the realm.
*Possible solution:*
a) add mapping from identity attribute to identity principal into LdapRealm (add "username-attribute into ldap-realm and map this identity attribute to NamePrincipal when defined)
b) to use identity attribute instead of special method for principal to add this possibility into all realms at once?
[~dlofthouse] do you think this should be solved for LDAP only, or on higher level?
Not sure but mabe the problem can occure also in FileSystemRealm - if there is user "firstUser", user can log in successfully as "FIRSTUSER" on Windows too - so he can obtain two different principals - realm should normalize it, or better use user input only for search, but the principal obtain from database :(
> Elytron ldap-realm is not able to use LDAP attribute as principal
> -----------------------------------------------------------------
>
> Key: ELY-857
> URL: https://issues.jboss.org/browse/ELY-857
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> In Elytron ldap-realm is currently not possible to obtain username from LDAP attribute which is different than rdn-identifier. It means that username of identity is always the same as value of rdn-identifier attribute.
> It can cause issues when ldap-realm is used for authentication and another realm is used for authorization since data for realm authorization can depend on assigned name during authentication.
> Example:
> It seems that ldap-realm cannot be configured for following scenario: User with credentials {{someUser}}/{{Password}} is authenticated and name {{AuthenticatedUser}} is assigned to them (e.g. when calling {{./jboss-cli.sh -c -u=someUser -p=Password ':whoami'}}, then {{AuthenticatedUser}} should be printed). Following ldif is used:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=someUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: someUser
> cn: some User
> sn: AuthenticatedUser
> userPassword: Password
> {code}
> Mentioned ldif works correctly with legacy security solution.
> This missing feature can cause that migration from legacy security solution will not be possible -> we request blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months