SAML SSO troubleshooting

By: Konstantins Martuzenoks user 09 Jun 2016 at 6:02 a.m. CDT

7 Responses
Konstantins Martuzenoks gravatar
Hello, gluu support people. Currently I am trying to setup SAML SSO with an app using Gluu server and AD as its backend LDAP server. Following gluu documentation I have configured Cache Refresh and authentication flow so that authentication to the gluu server works flawlessly with backend user credentials. But SAML authentication does not work as expected. This is the SAML authentication request sent by the app: ``` <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_f53c4b0a507c2d375a3e" Version="2.0" IssueInstant="2016-06-09T10:25:36.565Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://meteor.lv/login/callback" Destination="https://gluu.enterprise.com/idp/profile/SAML2/Redirect/SSO" > <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://meteor.lv/login/callback</saml:Issuer> <samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /> <samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact" > <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest> ``` In Idp logs I was getting an error: ``` 07:07:13.956 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:164] - Error occured attempting authentication javax.naming.directory.InvalidSearchFilterException: invalid attribute description at com.sun.jndi.ldap.Filter.encodeSimpleFilter(Filter.java:446) ~[na:1.7.0_95] at com.sun.jndi.ldap.Filter.encodeFilter(Filter.java:146) ~[na:1.7.0_95] ``` Then, reading the support forum tickets I have changed one string in login.config.vm from userField="$userField" to userField="uid". But this change did not help me. After that I start to get another error: ``` 09:32:15.110 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:75] - invoking checkServerTrusted for edu.vt.middleware.ldap.ssl.HostnameVerifyingTrustManager@33ba9029 09:32:15.110 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:127] - Verify with the following parameters: 09:32:15.110 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:128] - hostname = localhost 09:32:15.110 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:129] - cert = CN=localhost, O=OpenDJ RSA Self-Signed Certificate 09:32:15.110 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:202] - verifyDNS using subjectAltNames = [] 09:32:15.110 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:219] - verifyDNS using CN = [localhost] 09:32:15.116 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:225] - verifyDNS found hostname match: localhost 09:32:15.116 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:90] - invoking getAcceptedIssuers invoked for sun.security.ssl.X509TrustManagerImpl@100c6160 09:32:15.116 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:90] - invoking getAcceptedIssuers invoked for edu.vt.middleware.ldap.ssl.HostnameVerifyingTrustManager@33ba9029 09:32:15.167 - DEBUG [edu.vt.middleware.ldap.handler.DefaultConnectionHandler:163] - Error connecting to LDAP URL: ldap://localhost:1636 javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials] at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3088) ~[na:1.7.0_95] at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3034) ~[na:1.7.0_95] at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2836) ~[na:1.7.0_95] ``` Could you, please, suggest something to make it work?
U1404
closed

Answers

By Mohib Zico Account Admin 09 Jun 2016 at 8:53 a.m. CDT

Copy
Mohib Zico gravatar
>> Error connecting to LDAP URL: ldap://localhost:1636 This is one problem. You are trying to bind 1636 ( which is SSL port ) with 'ldap' [ no ldaps ].

By Aliaksandr Samuseu staff 09 Jun 2016 at 12:14 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Konstantins. May I ask you to provide screenshot of the login page you are being presented with right after you are redirected from this very SP (which SAML request you provided in the first post) to Gluu?

By Konstantins Martuzenoks user 09 Jun 2016 at 1:32 p.m. CDT

Copy
Konstantins Martuzenoks gravatar
Hi, there. Well, I get redirected to Shibboleth standard login page, which I did not modify: ![page after redirect](http://postimg.org/image/e6qalnxu3/ "Shibboleth login page")
Video or screenshot link

By Aliaksandr Samuseu staff 09 Jun 2016 at 1:59 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Thanks, please also provide output of this (within the container): `cat /opt/idp/conf/login.config`

By Konstantins Martuzenoks user 09 Jun 2016 at 2:22 p.m. CDT

Copy
Konstantins Martuzenoks gravatar
Hi, here is the content of login.config: ``` ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required host="ldaps://localhost:1636" subtreeSearch="true" base="o=gluu" subtreeSearch="true" serviceUser="cn=Directory Manager" serviceCredential="SOMEPASSWORD" userField="uid"; }; ```

By Aliaksandr Samuseu staff 09 Jun 2016 at 2:51 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Okay, thanks. I just needed to confirm my suspicion - yes, it's a known issue. It's rarely being reported because usually SP doesn't send preferred authentication context/method, so Gluu's Shibboleth package selects the default "AuthenticationMethod". Still, our configuration files seems to contain "PasswordProtectedTransport" method too. Back then when I asked our dev guys whether it's intended or just some legacy leftovers, they said it's intended and should work. It seems it still doesn't. I'll create an inquiry on github to sort it out once and for all. Here what you can do to circumvent it. This is caused by your SP including ``` <samlp:RequestedAuthnContext Comparison="exact"> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> ``` in the initial request. If you can control it, please make sure that no particular AuthnContext is requested. Then you'll be using our main and 100% supported log in flow through our oxTrust web UI.

By Konstantins Martuzenoks user 10 Jun 2016 at 2:43 a.m. CDT

Copy
Konstantins Martuzenoks gravatar
Aha! Yes, indeed. After removing this part from authentication request it works. Now it redirects to: https://<host.domain>/oxauth/login Where users get successfully authenticated. Thank you so much Aliaksandr for helping me out and solving this issue!

Post an answer