[JBoss JIRA] (JGRP-2034) SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2034?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2034:
---------------------------
Fix Version/s: 3.6.13
(was: 3.6.12)
> SASLTest-functional and SASL_SimpleAuthorizingCallbackTest-functional fails on IBM jdk 1.8
> ------------------------------------------------------------------------------------------
>
> Key: JGRP-2034
> URL: https://issues.jboss.org/browse/JGRP-2034
> Project: JGroups
> Issue Type: Bug
> Reporter: Ivan Straka
> Assignee: Tristan Tarrant
> Fix For: 3.6.13
>
>
> We see these two tests failing on IBM jdk 1.8
> org.jgroups.protocols.SASLTest-functional
> org.jgroups.protocols.SASL_SimpleAuthorizingCallbackTest-functional
> This issue may be related to https://issues.jboss.org/browse/JGRP-1993 somehow.
> There is standard output of tests.
> {code}
> ------------- testSASLDigestMD5 -----------
> -------------------------------------------------------------------
> GMS: address=A, cluster=SaslTest
> -------------------------------------------------------------------
> 521823 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
> 521823 [DEBUG] GMS: A: installing view [A|0] (1) [A]
> 521823 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> -------------------------------------------------------------------
> GMS: address=B, cluster=SaslTest
> -------------------------------------------------------------------
> 521825 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
> 521826 [DEBUG] GMS: B: sending JOIN(B) to A
> 521826 [TRACE] SASL: B: received CHALLENGE from A
> 521827 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 524826 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
> 524827 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
> 524827 [DEBUG] GMS: B: sending JOIN(B) to A
> 524828 [TRACE] SASL: B: received CHALLENGE from A
> 524828 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 526826 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@ad737f58
> ------------- testSASLDigestMD5Failure -----------
> -------------------------------------------------------------------
> GMS: address=A, cluster=SaslTest
> -------------------------------------------------------------------
> 529863 [TRACE] GMS: A: no members discovered after 3000 ms: creating cluster as first member
> 529864 [DEBUG] GMS: A: installing view [A|0] (1) [A]
> 529864 [DEBUG] GMS: A: created cluster (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> -------------------------------------------------------------------
> GMS: address=B, cluster=SaslTest
> -------------------------------------------------------------------
> 529866 [TRACE] GMS: B: discovery took 1 ms, members: 1 rsps (1 coords) [done]
> 529866 [DEBUG] GMS: B: sending JOIN(B) to A
> 529867 [TRACE] SASL: B: received CHALLENGE from A
> 529867 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 532867 [WARN] GMS: B: JOIN(B) sent to A timed out (after 3000 ms), on try 1
> 532867 [TRACE] GMS: B: discovery took 0 ms, members: 1 rsps (1 coords) [done]
> 532867 [DEBUG] GMS: B: sending JOIN(B) to A
> 532868 [TRACE] SASL: B: received CHALLENGE from A
> 532869 [WARN] SASL: B: failed to validate CHALLENGE from A, token
> javax.security.sasl.SaslException: DIGEST-MD5: Error acquiring realm, authentication ID or password
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:380) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at com.ibm.security.sasl.digest.DigestMD5Client.evaluateChallenge(DigestMD5Client.java:236) ~[ibmsaslprovider.jar:8.0 build_20150506]
> at org.jgroups.auth.sasl.SaslClientContext.evaluateChallenge(SaslClientContext.java:119) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.addHeader(SaslClientContext.java:92) ~[classes/:?]
> at org.jgroups.auth.sasl.SaslClientContext.nextMessage(SaslClientContext.java:72) ~[classes/:?]
> at org.jgroups.protocols.SASL.up(SASL.java:239) [classes/:?]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) [classes/:?]
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) [classes/:?]
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) [classes/:?]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) [classes/:?]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:645) [classes/:?]
> at org.jgroups.protocols.Discovery.up(Discovery.java:296) [classes/:?]
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1567) [classes/:?]
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1783) [classes/:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153) [?:1.8.0-internal]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:1.8.0-internal]
> at java.lang.Thread.run(Thread.java:785) [?:1.8.0-internal]
> Caused by: java.io.IOException: Invalid realm A
> at org.jgroups.auth.sasl.SimpleAuthorizingCallbackHandler.handle(SimpleAuthorizingCallbackHandler.java:119) ~[classes/:?]
> at com.ibm.security.sasl.digest.DigestMD5Client.processChallenge(DigestMD5Client.java:353) ~[ibmsaslprovider.jar:8.0 build_20150506]
> ... 16 more
> 534867 [WARN] SASL: failed to validate SaslHeader from B, header: payload=[B@6f6c2511
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7865) We cannot define CS file location outside of EAP directory
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7865?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7865:
----------------------------------------
Is there a management path resource named java.io.tmpdir. The relative-to attribute is a reference to a management path, not to the value of a system property.
> We cannot define CS file location outside of EAP directory
> ----------------------------------------------------------
>
> Key: WFLY-7865
> URL: https://issues.jboss.org/browse/WFLY-7865
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> We aren't able define location of CS file outside of EAP directory. When user has CS file on NFS he isn't able to reach this file.
> Define CS file location to JBOSS_HOME/Standalone/data directory:
> {code}
> /subsystem=elytron/credential-store=CredStore001:add(uri="cr-store://test/cs123.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.data.dir)
> {code}
> When I try set relative to TEMP directory:
> {code}
> /subsystem=elytron/credential-store=CredStore002:add(uri="cr-store://test/cs123.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=java.io.tmpdir)
> {code}
> I get this error
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"java.io.tmpdir\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore002 is missing [jboss.server.path.\"java.io.tmpdir\"]"]
> },
> "rolled-back" => true
> }
> {code}
> *NOTE:*
> *relative-to* is resolved here https://github.com/wildfly-security/elytron-subsystem/blob/c223be428b9a6f...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7865) We cannot define CS file location outside of EAP directory
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7865?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-7865 at 1/10/17 10:15 AM:
------------------------------------------------------------------
Is there a management path resource named java.io.tmpdir? The relative-to attribute is a reference to a management path, not to the value of a system property.
was (Author: brian.stansberry):
Is there a management path resource named java.io.tmpdir. The relative-to attribute is a reference to a management path, not to the value of a system property.
> We cannot define CS file location outside of EAP directory
> ----------------------------------------------------------
>
> Key: WFLY-7865
> URL: https://issues.jboss.org/browse/WFLY-7865
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> We aren't able define location of CS file outside of EAP directory. When user has CS file on NFS he isn't able to reach this file.
> Define CS file location to JBOSS_HOME/Standalone/data directory:
> {code}
> /subsystem=elytron/credential-store=CredStore001:add(uri="cr-store://test/cs123.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=jboss.server.data.dir)
> {code}
> When I try set relative to TEMP directory:
> {code}
> /subsystem=elytron/credential-store=CredStore002:add(uri="cr-store://test/cs123.jceks?create.storage=true", credential-reference={clear-text=pass123}, relative-to=java.io.tmpdir)
> {code}
> I get this error
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.server.path.\"java.io.tmpdir\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.credential-store.CredStore002 is missing [jboss.server.path.\"java.io.tmpdir\"]"]
> },
> "rolled-back" => true
> }
> {code}
> *NOTE:*
> *relative-to* is resolved here https://github.com/wildfly-security/elytron-subsystem/blob/c223be428b9a6f...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7868) Embedded server, elytron filesystem-realm creation requires reload
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7868?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-8187 to WFLY-7868:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7868 (was: JBEAP-8187)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: User Experience)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR10)
> Embedded server, elytron filesystem-realm creation requires reload
> ------------------------------------------------------------------
>
> Key: WFLY-7868
> URL: https://issues.jboss.org/browse/WFLY-7868
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Brian Stansberry
>
> In embedded server, when elytron filesystem realm is created command response is not marked with {{reload-required}}. However subsequent attempt to use this filesystem realm fails.
> When reload is called between this 2 commands it is OK.
> When trying on standalone server it is OK.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1939) Tabulator in CLI could suggest actual values for attributes for operations
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1939?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1939:
----------------------------------------------
[~mnovak], I would be interested in knowing the set of operation arguments in WFLY that would benefit from such a support. It would be very helpful if you could list (in this JIRA entry) all the places that user_experience testing has found (in elytron subsystem, other subsystems, ...).
Knowing the main operation's argument that could be retrieved from the result of an operation call, read-resource property name, read-attribute even from the list of children names (e.g.: logger names). would greatly help design a possible solution.
Thank-you.
JF
> Tabulator in CLI could suggest actual values for attributes for operations
> --------------------------------------------------------------------------
>
> Key: WFCORE-1939
> URL: https://issues.jboss.org/browse/WFCORE-1939
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Miroslav Novak
> Labels: user_experience
>
> There are number of cases where is necessary to execute CLI operation to actually get value for attribute to another CLI operation. For example I want to list all messages for subscription on the topic then it's necessary to get names of all subscriptions by:
> {code}
> [standalone@172.16.10.17:9990 /] /subsystem=messaging-activemq/server=default/jms-topic=HQ_ProductFamilyT23:list-all-subscriptions
> {
> "outcome" => "success",
> "result" => [
> {
> "durable" => true,
> "queueName" => "172\\.16\\.10\\.15_VM1_SPAgent55_0.SP_CallForOffersEH_55_EHID_1PF4",
> "clientID" => "172.16.10.15_VM1_SPAgent55_0",
> "messageCount" => 0,
> "deliveringCount" => 0,
> "name" => "SP_CallForOffersEH_55_EHID_1PF4",
> "consumers" => [{
> "creationTime" => 1478261489444L,
> "consumerID" => 4,
> "browseOnly" => false,
> "connectionID" => "-1638816479",
> "sessionID" => "d1149360-a287-11e6-bb34-97e27f67b29e"
> }]
> },
> {
> "durable" => true,
> "queueName" => "172\\.16\\.10\\.18_VM1_SPAgent23_0.SP_CallForOffersEH_23_EHID_1PF0",
> "clientID" => "172.16.10.18_VM1_SPAgent23_0",
> "messageCount" => 0,
> "deliveringCount" => 0,
> "name" => "SP_CallForOffersEH_23_EHID_1PF0",
> "consumers" => [{
> "creationTime" => 1478261516648L,
> "consumerID" => 0,
> "browseOnly" => false,
> "connectionID" => "-1794279882",
> "sessionID" => "e14e5343-a287-11e6-9311-4d8e66b2ef14"
> }]
> }
> ]
> }
> {code}
>
> so name of subscription {{SP_CallForOffersEH_55_EHID_1PF4}} could be used in: {code}
> [standalone@172.16.10.17:9990 /] /subsystem=messaging-activemq/server=default/jms-topic=HQ_ProductFamilyT23:list-messages-for-subscription(queue-name=SP_CallForOffersEH_55_EHID_1PF4){code}
> The improvement would allow to just press tab in: {code}
> [standalone@172.16.10.17:9990 /] /subsystem=messaging-activemq/server=default/jms-topic=HQ_ProductFamilyT23:list-messages-for-subscription(queue-name=... <-- tab here would suggest which queues are available {code}
> and it would suggest queue names of available subscriptions.
> There are more places like this - for example :
> {code}
> /subsystem=messaging-activemq/server=default:rollback-prepared-transaction(transaction-as-base-64=... <-- tab here
> {code}
> would provide available prepared transactions which can be commit.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-857) Elytron ldap-realm is able to obtain username only from rdn-identifier attribute
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-857:
--------------------------------
Looks more like problem of security-domain, then problem of LdapRealm - need to use identity attribute as authorization name. (instead of pure rewritting of username written by user)
> 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: 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 able to obtain username only from rdn-identifier attribute
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-857?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina reassigned ELY-857:
------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> 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: 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