[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-856:
--------------------------------
This issue is similar to ELY-794 - it would be solved, if we could use any LDAP attribute (or identity attribute) as wildcard in filter of attribute mapping.
(But we would need to be able to address entity of attribute by DN!)
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Example:
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {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: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works 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)
8 years, 11 months
[JBoss JIRA] (ELY-856) Elytron ldap-realm does not support principal to group mapping (memberOf)
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-856?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-856:
---------------------------
Summary: Elytron ldap-realm does not support principal to group mapping (memberOf) (was: Elytron ldap-realm does not support principal to group mapping)
> Elytron ldap-realm does not support principal to group mapping (memberOf)
> -------------------------------------------------------------------------
>
> Key: ELY-856
> URL: https://issues.jboss.org/browse/ELY-856
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
>
> Elytron ldap-realm is not able to work with LDAP which uses principal to group mapping. It seems that there is currently no way how to configure principal to group mapping in application server.
> Example:
> Role {{SomeRole}} is currently not able to be assigned to user {{someUser}} when following ldif is used. In this case principal to group mapping is provided by attribute {{description}}, but in can be provided by any attribute (e.g. memberOf). User {{thisUserIsNotUsed}} is used only for simpler reproduction of issue.
> {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: User
> userPassword: Password
> description: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> dn: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: thisUserIsNotUsed
> cn: this User Is Not Used
> sn: this User Is Not Used
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=SomeRole,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: SomeRole
> member: uid=thisUserIsNotUsed,ou=People,dc=jboss,dc=org
> {code}
> Mentioned ldif works 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)
8 years, 11 months
[JBoss JIRA] (ELY-858) Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-858:
--------------------------------
Summary: Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
Key: ELY-858
URL: https://issues.jboss.org/browse/ELY-858
Project: WildFly Elytron
Issue Type: Bug
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
In case when attribute {{identity-mapping.search-base-dn}} from Elytron ldap-realm is missing in configuration then calling ldap-realm during authentication causes NullPointerException.
Following exception is thrown to server log:
{code}
ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01108: Ldap-backed realm identity search failed
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:976)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:605)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:548)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:516)
at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1785)
at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:656)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:854)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:778)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:895)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:726)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at org.jboss.as.naming.InitialContext.getURLScheme(InitialContext.java:160)
at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:128)
at javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:106)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:319)
at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:945)
... 47 more
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-858) Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-858?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-858:
-----------------------------
Affects Version/s: 1.1.0.Beta16
> Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
> ---------------------------------------------------------------------------
>
> Key: ELY-858
> URL: https://issues.jboss.org/browse/ELY-858
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when attribute {{identity-mapping.search-base-dn}} from Elytron ldap-realm is missing in configuration then calling ldap-realm during authentication causes NullPointerException.
> Following exception is thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:976)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:605)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:548)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:516)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1785)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:656)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:854)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:778)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:895)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:726)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.naming.InitialContext.getURLScheme(InitialContext.java:160)
> at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:128)
> at javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:106)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:319)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:945)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-858) Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-858?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-858:
-----------------------------
Component/s: Realms
> Missing search-base-dn in identity-mapping of Elytron ldap-realm causes NPE
> ---------------------------------------------------------------------------
>
> Key: ELY-858
> URL: https://issues.jboss.org/browse/ELY-858
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when attribute {{identity-mapping.search-base-dn}} from Elytron ldap-realm is missing in configuration then calling ldap-realm during authentication causes NullPointerException.
> Following exception is thrown to server log:
> {code}
> ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01108: Ldap-backed realm identity search failed
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:976)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:605)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:548)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:516)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1785)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:656)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:854)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:778)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:895)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:726)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1680)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:208)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.naming.InitialContext.getURLScheme(InitialContext.java:160)
> at org.jboss.as.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:128)
> at javax.naming.directory.InitialDirContext.getURLOrDefaultInitDirCtx(InitialDirContext.java:106)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:286)
> at org.wildfly.security.auth.realm.ldap.DelegatingLdapContext.search(DelegatingLdapContext.java:319)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity$LdapSearch.search(LdapSecurityRealm.java:945)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is able to obtain username only from rdn-identifier attribute
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-857:
-----------------------------
Affects Version/s: 1.1.0.Beta16
> Elytron ldap-realm is able to obtain username only from rdn-identifier attribute
> --------------------------------------------------------------------------------
>
> Key: ELY-857
> URL: https://issues.jboss.org/browse/ELY-857
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta16
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> 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)
8 years, 11 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is able to obtain username only from rdn-identifier attribute
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-857:
-----------------------------
Component/s: Realms
> Elytron ldap-realm is able to obtain username only from rdn-identifier attribute
> --------------------------------------------------------------------------------
>
> 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: Darran Lofthouse
> 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)
8 years, 11 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is able to obtain username only from rdn-identifier attribute
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-857:
--------------------------------
Summary: Elytron ldap-realm is able to obtain username only from rdn-identifier attribute
Key: ELY-857
URL: https://issues.jboss.org/browse/ELY-857
Project: WildFly Elytron
Issue Type: Bug
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
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)
8 years, 11 months
[JBoss JIRA] (ELY-794) Missing input username wildcard for role/attribute search in Elytron ldap-realm
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-794?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-794:
--------------------------------
Issue ELY-856 is similar problem.
> Missing input username wildcard for role/attribute search in Elytron ldap-realm
> -------------------------------------------------------------------------------
>
> Key: ELY-794
> URL: https://issues.jboss.org/browse/ELY-794
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta13
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
>
> Scenario: I am trying to assign role from LDAP to user. I would like to use input username (e.g. admin) in filter, not full user DN (e.g. uid=admin,ou=People,dc=jboss,dc=org). It seems Elytron ldap-realm does not provide any wildcard which can be used for input username.
> In EAP 7.0 (with PicketBox), LdapExtLoginModule provides roleFilter option which filter can contain following wildcards:
> * {{\{0\}}} - for input username
> * {{\{1\}}} - for authenticated full user DN
> It seems that Elytron supports only wildcard for authenticated full user DN (through {{\{0\}}} wildcard). Wildcard for input username should be added.
> It would be useful, when order of wildcards will be the same as in EAP 7.0 - i.e. not just add the new {{\{1\}}} for input username, but use {{\{0\}}} for input username and {{\{1\}}} for authenticated full user DN. This order is also better due to wildcard {{\{0\}}} will mean the same in identity filter and in role/attribute filter.
> Missing this feature in Elytron can lead to situation when migration from PicketBox to Elytron will not be possible since LDAP structure for role assignment used by legacy solution will not be able to work correctly with Elytron.
> Example of usage:
> I would like to use filter like {{(description=SOME_INPUT_USERNAME_WILDCARD)}} for assigning role JBossAdmin to user jduke in following ldif:
> {code}
> dn: ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password
> dn: uid=notUsedUser,ou=People,dc=jboss,dc=org
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: notUsedUser
> cn: not used user
> sn: notUsedUser
> userPassword: Password
> dn: ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: organizationalUnit
> ou: Roles
> dn: cn=JBossAdmin,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: JBossAdmin
> member: uid=notUsedUser,ou=People,dc=jboss,dc=org
> description: jduke
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months