Elytron ldap-realm migration

[eng.dan...@gmail.com]

Hi everyone,

 

With the new wildfly version (25.0.0), i'm  trying to migrate PicketLink LdapLoginModule to Elytron.

 

My previous configuration using legacy security

 

<security-domain name="MySecurityDomain" cache-type="default">

     <authentication>

<login-module code="Ldap" flag="sufficient">

<module-option name="java.naming.provider.url" value="ldap://myactivedirectory:389/"/>

<module-option name="principalDNSuffix" value="@mydomain.local"/>

<module-option name="rolesCtxDN" value="DC=mydomain,DC=local"/>

<module-option name="uidAttributeID" value="sAMAccountName"/>

<module-option name="roleAttributeID" value="memberOf"/>

<module-option name="roleAttributeIsDN" value="true"/>

</login-module>

    </authentication>

</security-domain>

 

With this configuration (Legacy LdapLoginModule) , i was able to establish a connection with myactivedirectory using the user credentials (user trying to login).

Using Elytron with the following configuration everything works fine. However i would like to remove the principal and credential from dir-context, 

and establish the connection using user credentials (user trying to login) as i did using legacy security, because in some clients i don't have an available user to perform the ldap connection.

Is this possible with Elytron?

In, ldap-realm, i have set the property direct-verification to true. According to admin console, this is supposed to do what i want or i misunderstood?

"Does this realm support verification of credentials by directly connecting to LDAP as the account being authenticated?

Supports expressions. A modification to the attribute can only be applied to the runtime via a restart of all services, but does not require a full jvm restart." 

<security-domains>

<security-domain name="MySecurityDomain" default-realm="MySecurityRealm" permission-mapper="default-permission-mapper">

<realm name="MySecurityRealm" role-decoder="from-roles-attribute"/>

</security-domain>

</security-domains>

<security-realms>

...               

<ldap-realm name="MySecurityRealm" dir-context="myDirContext" direct-verification="true">

<identity-mapping rdn-identifier="sAMAccountName" search-base-dn="OU=users,DC=mydomain,DC=local">

<attribute-mapping>

<attribute from="name" to="Roles" filter="(member={1})" filter-base-dn="OU=groups,DC=mydomain,DC=local" role-recursion="1"/>

</attribute-mapping>

</identity-mapping>

</ldap-realm>

</security-realms>

<dir-contexts>

<dir-context name="myDirContext" url="ldap://myactivedirectory:389" principal="CN=AD Connector,OU=users,DC=mydomain,DC=local">

<credential-reference clear-text="mypassword"/>

</dir-context>

</dir-contexts>

if i remove the principal and credential-reference from dir-context, login fails.

DEBUG [org.wildfly.security] (default task-1) Obtaining lock for identity [dnovo]...

DEBUG [org.wildfly.security] (default task-1) Obtained lock for identity [dnovo].

DEBUG [org.wildfly.security] (default task-1) Creating [class javax.naming.directory.InitialDirContext] with environment:

DEBUG [org.wildfly.security] (default task-1)     Property [com.sun.jndi.ldap.read.timeout] with value [60000]

DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.referral] with value [ignore]

DEBUG [org.wildfly.security] (default task-1)     Property [com.sun.jndi.ldap.connect.pool] with value [false]

DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.security.authentication] with value [simple]

DEBUG [org.wildfly.security] (default task-1)     Property [com.sun.jndi.ldap.connect.timeout] with value [5000]

DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.provider.url] with value [ldap://myactivedirectory:389]

DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]

DEBUG [org.wildfly.security] (default task-1) [javax.naming.ldap.InitialLdapContext@42b0441b] successfully created. Connection established to LDAP server.

DEBUG [org.wildfly.security] (default task-1) Trying to create identity for principal [dnovo].

DEBUG [org.wildfly.security] (default task-1) Executing search [(sAMAccountName={0})] in context [OU=users,DC=mydomain,DC=local] with arguments [dnovo]. Returning attributes are [null]. Binary attributes are [null].

DEBUG [org.wildfly.security] (default task-1) Context [javax.naming.ldap.InitialLdapContext@42b0441b] was closed. Connection closed or just returned to the pool.

ERROR [stderr] (default task-1) javax.servlet.ServletException: UT010031: Login failed

 

Thanks in advance.

[Ashpan Raskar]

Hey,
Setting direct-verification="true" is the right approach.

Do you have any more details that I could use to reproduce this error you're receiving?

[Ashpan Raskar]

Quick update,

while I was trying to setup the same environment you had running I was able to replicate your issue, and while debugging in the trace logs I received a RealmUnavailableException. This indicated to me that the ldap realm was not able to connect to the url in the "dir-context". For me I had a typo in mine (from "ldap://localhost:11391" to "ldaps://localhost:11391"), once I changed that I was able to run it without any errors.

Below I have linked the environment I have (in the LdapTestCase.java file) and the xml configuration is in the ldap.xml file.

https://github.com/Ashpan/wildfly-core/blob/f943def76c2bdf893f84318df69b4392dd94f6db/elytron/src/test/java/org/wildfly/extension/elytron/LdapTestCase.java#L298-L308

https://github.com/Ashpan/wildfly-core/blob/f943def76c2bdf893f84318df69b4392dd94f6db/elytron/src/test/resources/org/wildfly/extension/elytron/ldap.xml#L42-L45

Please let me know if you have any questions

[Daniel Novo]

Hi Ashpan,

I checked your github and tried to follow your configuration:

Changes made:

<authentication-client>
   <authentication-configuration name="ldapAuthConfig" authentication-name="CN=AD Connector,OU=users,DC=mydomain,DC=local">
      <credential-reference clear-text="mypassword"/>
    </authentication-configuration>
    <authentication-context name="ldapAuthContext">
       <match-rule match-host="myactivedirectory" match-protocol="ldap" authentication-configuration="ldapAuthConfig"/>
    </authentication-context>
   </authentication-client>

and in dir-context added authentication-context reference:

<dir-contexts>
   <dir-context name="BoardingDirContext" url="ldap://myactivedirectory:389" authentication-context="ldapAuthContext">                    
   </dir-context>
</dir-contexts>

With this configuration i'm able to successfully login. However, this was not the solution i was looking for. Instead of adding user/password in dir-context, they are now in authentication-configuration.

The goal is to connect to ldap server using the supplied user/password provided by the user in login form.

In your ldap.xml, in DirContextInsecure you do not provide any principal/credentials, but they seem to be referenced in authentication-client.

I was able to do this with picketlink (legacy security).

Another question, which logs should I enable to trace the setup? org.wildfly.elytron, org.wildfly.security? Are there any others?

Thanks for your help.

--
You received this message because you are subscribed to a topic in the Google Groups "WildFly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wildfly/8f5AAcoU7HY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/c5cbbf49-417a-46dc-ac94-cd550119fff6n%40googlegroups.com.

--

--------------

Daniel Novo

[Ashpan Raskar]

Hi Daniel,

I understand the issue that you are facing and it looks like it is some unexpected behaviour. I have opened a JIRA issue in WildFly-Core to track it's progress here.

I will update you here when this issue is investigated.

Regarding the trace logging, we use org.wildfly.security

[eng.dan...@gmail.com]

Hi Ashpan, 

Any ideia when to expected this issue to be solved? 

Thank you.

[Tomas Andersson]

Hi, I have a similar problem and wonder if there is any solution for me to make it work. I am trying to add an ldap login in an existing ejb client using the credentials provided by the user to login to ldap and fetch the roles. At the moment I am experimenting with the https://github.com/wildfly/quickstart/tree/main/ejb-security as a base. Like Daniel I get the ldap connection to work if I provide credentials in dir contexts(assume direct-verification set to true does not mean you have to use it):

                <ldap-realm name="LdapRealm" dir-context="ldap-connection" direct-verification="true">
                    <identity-mapping rdn-identifier="sAMAccountName" search-base-dn="ou=Users,ou=ad,dc=ad,dc=my,dc=se">
                        <attribute-mapping>
                            <attribute from="sAMAccountName" to="Roles" filter="(sAMAccountName={1})" filter-base-dn="ou=Users,ou=ad,dc=ad,dc=my,dc=se"/>
                        </attribute-mapping>
                    </identity-mapping>
                </ldap-realm>
                <caching-realm name="CachedLdapRealm" realm="LdapRealm"/>

            <dir-contexts>
                <dir-context name="ldap-connection" url="ldap://myad:389" principal="myPrincipal">
                    <credential-reference clear-text="myCredential>
                </dir-context>
            </dir-contexts>

As a first step I am passing in the user credentials in the wildfly-gonfig.xml(haven´t found any good example of how to set them though):

configuration>
    <authentication-client xmlns="urn:elytron:1.0">
        <authentication-rules>
            <rule use-configuration="ldapAuthConfig"/>
        </authentication-rules>
        <authentication-configurations>
            <configuration name="ldapAuthConfig">
                <sasl-mechanism-selector selector="DIGEST-MD5"/>
                <set-authorization-name name="myPrincipal"/>
                <set-user-name name="myPrincipal" />
                <credentials>
                    <clear-password password="myPassword" />
                </credentials>
                <set-mechanism-realm name="CachedLdapRealm" />
            </configuration>
        </authentication-configurations>
    </authentication-client>
</configuration>

My intention if I do get this to work is to configure this programatically with AuthenticationConfiguration and AuthenticationContext and set the user credentials dynamically.

2022-02-23 12:01:22,196 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [CachedLdapRealm]
2022-02-23 12:01:22,197 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = myPrincipal
2022-02-23 12:01:22,198 TRACE [org.wildfly.security] (default task-1) Principal assigning: [myPrincipal], pre-realm rewritten: [myPrincipal], realm name: [CachedLdapRealm], post-realm rewritten: [myPrincipal], realm rewritten: [myPrincipal]
2022-02-23 12:01:22,198 DEBUG [org.wildfly.security] (default task-1) Obtaining lock for identity [myPrincipal]...
2022-02-23 12:01:22,198 DEBUG [org.wildfly.security] (default task-1) Obtained lock for identity [myPrincipal].
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1) Creating [class javax.naming.directory.InitialDirContext] with environment:
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.security.credentials] with value [******]
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.security.authentication] with value [simple]
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.provider.url] with value [ldap://myad:389]
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1)     Property [com.sun.jndi.ldap.read.timeout] with value [60000]
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1)     Property [com.sun.jndi.ldap.connect.pool] with value [false]
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1)     Property [com.sun.jndi.ldap.connect.timeout] with value [5000]
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.security.principal] with value [myPrincipal]
2022-02-23 12:01:22,202 DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.referral] with value [ignore]
2022-02-23 12:01:22,203 DEBUG [org.wildfly.security] (default task-1)     Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory]
2022-02-23 12:01:22,294 DEBUG [org.wildfly.security] (default task-1) [javax.naming.ldap.InitialLdapContext@283c9bf6] successfully created. Connection established to LDAP server.
2022-02-23 12:01:22,295 DEBUG [org.wildfly.security] (default task-1) Trying to create identity for principal [myPrincipal].
2022-02-23 12:01:22,296 DEBUG [org.wildfly.security] (default task-1) Executing search [(sAMAccountName={0})] in context [ou=Users,ou=ad,dc=ad,dc=my,dc=se] with arguments [myPrincipal]. Returning attributes are [null]. Binary attributes are [null].

Nevermind the dysfunctional search, I haven´t looked into that yet but the important part is that I was allowed to search at all.

But what I want to do is to use the credentials provided by the user in the client. 

When changing dir-contexts to:        

<dir-contexts>

                <dir-context name="ldap-connection" url="ldap://myad:389" />
</dir-contexts>

I get:

2022-02-23 12:42:54,992 DEBUG [org.wildfly.security] (default task-1) [javax.naming.ldap.InitialLdapContext@548b2bdc] successfully created. Connection established to LDAP server.
2022-02-23 12:42:55,058 TRACE [org.wildfly.security.sasl.digest] (default task-1) SASL Negotiation Failed
2022-02-23 12:42:55,059 TRACE [org.jboss.remoting.remote.server] (default task-1) Server sending authentication rejected: javax.security.sasl.SaslException: ELY05053: Callback handler failed for unknown reason [Caused by java.io.IOException: org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context]
...
Caused by: javax.naming.NamingException: [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C0907E9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580]; remaining name ''

So basically the same as I would get through ldapsearch with incorrect credentials. I was expecting the credentials I provided in the client would be used to bind with direct-verification="true". Need to get this to work in production or quickly think of another security solution. 

I may definitely have configured this wrong but given I found this thread perhaps I am not? Would much appreciate any pointers towards a solution. 

[Daniel Novo]

Hi Ashpan,

Sorry to insist, I have been following the jira https://issues.redhat.com/browse/WFCORE-5643, and it is still unresolved.

I really need this, do you have any idea when this issue will be resolved?

Thank you. Regards

You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/dd80b0e6-b31e-41cd-ae69-d2123c354960n%40googlegroups.com.

--

--------------

Daniel Novo