IDP invalid attribute description

By: Vladimir Rudenko user 06 Apr 2016 at 7:57 a.m. CDT

17 Responses
Vladimir Rudenko gravatar
Hi, I try to connect my website with Gluu SAML IDP. Gluu server I install on ubuntu 14.04 with last updates. In Gluu admin page I added new Trust Relationship for my website. Also I create user "test" in Manage People tab. Website metadata: ``` <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2016-04-08T12:44:44Z" cacheDuration="PT604800S" entityID="http://myapp.example.com"> <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> MIIDQTCCAimgAwIBAgIJANfFZBrohjOnMA0GCSqGSIb3DQEBCwUAMDcxCzAJBgNVBAYTAkFVMQswCQYDVQQIDAJWTjELMAkGA1UEBwwCdm4xDjAMBgNVBAoMBWxvY2FsMB4XDTE2MDQwNTE3NDUzMVoXDTI2MDQwNTE3NDUzMVowNzELMAkGA1UEBhMCQVUxCzAJBgNVBAgMAlZOMQswCQYDVQQHDAJ2bjEOMAwGA1UECgwFbG9jYWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGxC6paPYlGz5XJQWrV0AK4t+le8bh4RjXDVMKrUAPWV/W6O5BNBAiNkltg0+Tu4GEbtoaCPRVcMSGs05hxkDz1RgG2yhW/v/vb0273vdRMHG569DVYGAiY4ERvHyKKsILzU+nzGTMiWspKhXGkwL+RYcGT1xBrIMV47ilkIpp39XwrmRbMl/Qro7ZHOBuP8RgRYh3xuQaNfbwWWzOFuoo59PTYrIryGuQtpoZQa2Wkv7hCrWFgVsn5WdHGYZkP+T4uwb5lyrztStmnURD5wX5Nl0nPzOEFWCJcSvSE3fCVpS0v0zYk7Ygkc5V76SyxYiLQnbCPlB4z7OUyStCN8FzAgMBAAGjUDBOMB0GA1UdDgQWBBSeoFl3eLC/GiCtFqMNFI1gAo8/XzAfBgNVHSMEGDAWgBSeoFl3eLC/GiCtFqMNFI1gAo8/XzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQABhNiM6ajSvBRPKDpPm0BBVWePiR0OHkTztz3OAvhxdW+HUT8ar4SLp9CFJCFhG2q6hCdQYGRzjCJC9YavBiqRl4/SIslGovGHIsrkrmkE64cy4R9V0on9KDPA951yGlavzl0OMrt+jAmBde3LdmvFqojyOceMBsaHWG7f66KOSgFERFDNBUn0Y+bqO07O5pfk/xZK4GjnIH7U1JR3fQEuVRYL7PS9Ud7P0XYvEyp76OvK6kKlNKZ3ULHts1SltXkxqLmqMKnDAbiHLU0h7rkl1XgzkHGq0DEobcsE+e0wOOHMOGMK0ld15tIPRC+H+fueHyWXhGJDCYCcMBew/N/4 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:KeyDescriptor use="encryption"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> MIIDQTCCAimgAwIBAgIJANfFZBrohjOnMA0GCSqGSIb3DQEBCwUAMDcxCzAJBgNVBAYTAkFVMQswCQYDVQQIDAJWTjELMAkGA1UEBwwCdm4xDjAMBgNVBAoMBWxvY2FsMB4XDTE2MDQwNTE3NDUzMVoXDTI2MDQwNTE3NDUzMVowNzELMAkGA1UEBhMCQVUxCzAJBgNVBAgMAlZOMQswCQYDVQQHDAJ2bjEOMAwGA1UECgwFbG9jYWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGxC6paPYlGz5XJQWrV0AK4t+le8bh4RjXDVMKrUAPWV/W6O5BNBAiNkltg0+Tu4GEbtoaCPRVcMSGs05hxkDz1RgG2yhW/v/vb0273vdRMHG569DVYGAiY4ERvHyKKsILzU+nzGTMiWspKhXGkwL+RYcGT1xBrIMV47ilkIpp39XwrmRbMl/Qro7ZHOBuP8RgRYh3xuQaNfbwWWzOFuoo59PTYrIryGuQtpoZQa2Wkv7hCrWFgVsn5WdHGYZkP+T4uwb5lyrztStmnURD5wX5Nl0nPzOEFWCJcSvSE3fCVpS0v0zYk7Ygkc5V76SyxYiLQnbCPlB4z7OUyStCN8FzAgMBAAGjUDBOMB0GA1UdDgQWBBSeoFl3eLC/GiCtFqMNFI1gAo8/XzAfBgNVHSMEGDAWgBSeoFl3eLC/GiCtFqMNFI1gAo8/XzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQABhNiM6ajSvBRPKDpPm0BBVWePiR0OHkTztz3OAvhxdW+HUT8ar4SLp9CFJCFhG2q6hCdQYGRzjCJC9YavBiqRl4/SIslGovGHIsrkrmkE64cy4R9V0on9KDPA951yGlavzl0OMrt+jAmBde3LdmvFqojyOceMBsaHWG7f66KOSgFERFDNBUn0Y+bqO07O5pfk/xZK4GjnIH7U1JR3fQEuVRYL7PS9Ud7P0XYvEyp76OvK6kKlNKZ3ULHts1SltXkxqLmqMKnDAbiHLU0h7rkl1XgzkHGq0DEobcsE+e0wOOHMOGMK0ld15tIPRC+H+fueHyWXhGJDCYCcMBew/N/4 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://myapp.example.com/sls"/> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://myapp.example.com/acs" index="1"/> </md:SPSSODescriptor> <md:Organization> <md:OrganizationName xml:lang="en-US">Name</md:OrganizationName> <md:OrganizationDisplayName xml:lang="en-US">Display Name</md:OrganizationDisplayName> <md:OrganizationURL xml:lang="en-US">http://myapp.example.com</md:OrganizationURL> </md:Organization> <md:ContactPerson contactType="technical"> <md:GivenName>name</md:GivenName> <md:EmailAddress>no@reply.com</md:EmailAddress> </md:ContactPerson> <md:ContactPerson contactType="support"> <md:GivenName>Support</md:GivenName> <md:EmailAddress>no@reply.com</md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor> ``` Auth Request: ``` <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN_65ab8b36732bc40df38a3c87cc34bd1623dc150f" Version="2.0" ProviderName="Display Name" IssueInstant="2016-04-06T12:33:48Z" Destination="https://idp.example.com/idp/profile/SAML2/Redirect/SSO" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="http://myapp.example.com/acs"> <saml:Issuer>http://myapp.example.com</saml:Issuer> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" AllowCreate="true" /> <samlp:RequestedAuthnContext Comparison="exact"> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest> ``` After request I go to the authentication page https://idp.example.com/idp/Authn/UserPassword I enter username and password, submit the form and nothing happened, page simple refresh. tail idp-process.log ``` 15:34:38.348 - TRACE [edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:117] - Attempting to retrieve IdP session cookie. 15:34:38.349 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:170] - Attempting to authenticate user test 15:34:38.403 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:194] - User authentication for test failed javax.security.auth.login.LoginException: invalid attribute description at edu.vt.middleware.ldap.jaas.LdapLoginModule.login(LdapLoginModule.java:167) ~[vt-ldap-3.3.8.jar:na] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_95] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_95] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_95] at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_95] at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) ~[na:1.7.0_95] at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) ~[na:1.7.0_95] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) ~[na:1.7.0_95] at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) ~[na:1.7.0_95] at java.security.AccessController.doPrivileged(Native Method) ~[na:1.7.0_95] at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) ~[na:1.7.0_95] at javax.security.auth.login.LoginContext.login(LoginContext.java:595) ~[na:1.7.0_95] at edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet.authenticateUser(UsernamePasswordLoginServlet.java:177) [shibboleth-identityprovider-2.4.3.jar:na] at edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet.service(UsernamePasswordLoginServlet.java:123) [shibboleth-identityprovider-2.4.3.jar:na] at javax.servlet.http.HttpServlet.service(HttpServlet.java:727) [servlet-api.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) [catalina.jar:7.0.55] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.55] at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) [tomcat7-websocket.jar:7.0.55] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [catalina.jar:7.0.55] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.55] at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50) [shibboleth-identityprovider-2.4.3.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [catalina.jar:7.0.55] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.55] at unimr.shib2.UniMrMemcachedServletFilter.doFilter(UniMrMemcachedServletFilter.java:53) [unimr-memcached-idp2.4-rev218.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [catalina.jar:7.0.55] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.55] at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:87) [shibboleth-identityprovider-2.4.3.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [catalina.jar:7.0.55] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.55] at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52) [shibboleth-common-1.4.3.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) [catalina.jar:7.0.55] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) [catalina.jar:7.0.55] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:203) [catalina.jar:7.0.55] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) [catalina.jar:7.0.55] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) [catalina.jar:7.0.55] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) [catalina.jar:7.0.55] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) [catalina.jar:7.0.55] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) [catalina.jar:7.0.55] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) [catalina.jar:7.0.55] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190) [tomcat-coyote.jar:7.0.55] at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611) [tomcat-coyote.jar:7.0.55] at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314) [tomcat-coyote.jar:7.0.55] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_95] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_95] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-coyote.jar:7.0.55] at java.lang.Thread.run(Thread.java:745) [na:1.7.0_95] 15:34:38.404 - TRACE [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:349] - Looking up LoginContext with key b3ae3e997f1d09a43431eb79efe67f141b403d7dc56ef861f98bc6558c28d59b from StorageService parition: loginContexts 15:34:38.405 - TRACE [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:355] - Retrieved LoginContext with key b3ae3e997f1d09a43431eb79efe67f141b403d7dc56ef861f98bc6558c28d59b from StorageService parition: loginContexts 15:34:38.497 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:150] - Redirecting to login page /login.jsp ``` Can you please help me to understand what I'm doing wrong?
None
closed

Answers

By Aliaksandr Samuseu staff 06 Apr 2016 at 9:06 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Vladimir. Can you simply log in with this user to web UI of your Gluu CE instance? Like, forget about Shibboleth part for a moment, can you just log in directly? Regards, Alex.

By Aliaksandr Samuseu staff 06 Apr 2016 at 9:08 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Please also provide full name/version of the Gluu package you are using, full version of your Linux distribution, and a bit more info about your setup and configuration. How much RAM does this host have? How much RAM have you assigned for tomcat when you were running ./setup.py? Have you created any custom attributes so far?

By Vladimir Rudenko user 06 Apr 2016 at 9:23 a.m. CDT

Copy
Vladimir Rudenko gravatar
Hi, Alex Yes I can login with this user URL:oxauth/login

By Vladimir Rudenko user 06 Apr 2016 at 9:38 a.m. CDT

Copy
Vladimir Rudenko gravatar
I install Gluu server according to the documentation [Deployment](https://www.gluu.org/docs/deployment/ubuntu/) on VirtualBox 5.0.16 r105871 cat /proc/version ``` Linux version 3.19.0-25-generic (buildd@lgw01-20) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 ``` uname -a ``` Linux myapp.gluu.com 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ``` lsb_release -a ``` No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.4 LTS Release: 14.04 Codename: trusty ``` Total RAM for host 5gb When I install with ./setup.py I chose default parameters of RAM for tomcat 1536mb warnings from setup_error.log ``` 15:02:48 04/05/16 [Tue Apr 05 15:02:46.709630 2016] [proxy:warn] [pid 3797:tid 140035377366912] AH01146: Ignoring parameter 'retry=5' for worker 'ajp://localhost:8009/oxauth' because of worker sharing [Tue Apr 05 15:02:46.709696 2016] [proxy:warn] [pid 3797:tid 140035377366912] AH01146: Ignoring parameter 'disablereuse=On' for worker 'ajp://localhost:8009/oxauth' because of worker sharing 15:02:48 04/05/16 update-rc.d: warning: /etc/init.d/tomcat missing LSB information update-rc.d: see <http://wiki.debian.org/LSBInitScripts> 15:02:48 04/05/16 update-rc.d: warning: start runlevel arguments (none) do not match memcached Default-Start values (2 3 4 5) update-rc.d: warning: stop runlevel arguments (none) do not match memcached Default-Stop values (0 1 6) 15:02:48 04/05/16 update-rc.d: warning: /etc/init.d/opendj missing LSB information update-rc.d: see <http://wiki.debian.org/LSBInitScripts> 15:02:48 04/05/16 update-rc.d: warning: /etc/init.d/tomcat missing LSB information update-rc.d: see <http://wiki.debian.org/LSBInitScripts> 15:02:48 04/05/16 update-rc.d: warning: start runlevel arguments (none) do not match apache2 Default-Start values (2 3 4 5) update-rc.d: warning: stop runlevel arguments (none) do not match apache2 Default-Stop values (0 1 6) ``` Where I can find a Gluu version? Usually I use service gluu-server-2.4.2 login|stop|start but I'm not sure that is a correct version of Gluu And no I don't create custom attributes. In the Trust Relationships for website I release one attribute **Email** Also I create one user named **Test** I don't change any configuration of Gluu.

By Aliaksandr Samuseu staff 06 Apr 2016 at 9:44 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
> Where I can find a Gluu version? For Ubuntu use `dpkg -l | grep gluu-server` > I chose default parameters of RAM for tomcat 1536mb I believe that's not enough. For production we usually recommend 4GB+, and I'm usually able to run it smoothly with 3GB allocation, but 1,5GB is way too low, that's when different kinds of issues may start to happen. Could you try to reinstall the instance and allocate at least 3GB for tomcat? Though it's a good question why we still use 1,5GB default in setup.py, it's a legacy from the age of 2.3.x when it was enough. I'll pass this to the dev team, we need to update it. What about custom attributes, have you created any?

By Aliaksandr Samuseu staff 06 Apr 2016 at 9:52 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
> And no I don't create custom attributes. In the Trust Relationships for website I release one attribute Email Got it, thanks. Please reinstall this instance and set it up with a sufficient memory allocations this time. If issue will still persist, we'll continue investigating it then

By Vladimir Rudenko user 06 Apr 2016 at 9:57 a.m. CDT

Copy
Vladimir Rudenko gravatar
Thanks Alex for quick reply! Ok I reinstall instance and try again dpkg -l | grep gluu-server ``` ii gluu-server-2.4.2 1-1 amd64 Gluu Server Community Edition ```

By Vladimir Rudenko user 06 Apr 2016 at 1:30 p.m. CDT

Copy
Vladimir Rudenko gravatar
Hi Alex, again I install Gluu server on another VM instance with total RAM 6gb and for tomcat 5GB, however I got the same error. I change **logging.xml** config to trace error and discovered that an error **invalid attribute description** triggered with **javax.naming.directory.InvalidSearchFilterException** ``` 21:00:20.602 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:90] - invoking getAcceptedIssuers invoked for sun.security.ssl.X509TrustManagerImpl@50d752a0 21:00:20.603 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:90] - invoking getAcceptedIssuers invoked for edu.vt.middleware.ldap.ssl.HostnameVerifyingTrustManager@482c6a53 21:00:20.656 - 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] at com.sun.jndi.ldap.Filter.encodeFilterString(Filter.java:74) ~[na:1.7.0_95] ``` Then I changed /opt/idp/conf/login.config I added the string **userFilter="uid={0}"** see documentation [Shibboleth IdPAuthUserPass](https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass) ``` ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required host="ldaps://localhost:1636" subtreeSearch="true" base="o=gluu" subtreeSearch="true" serviceUser="cn=Directory Manager" serviceCredential="fbwZlIvDOHXw" userFilter="uid={0}" userField=""; }; ``` Now it seems work normal. However I'm confused, please see this ticket [ticket](https://support.gluu.org/other/saml-idp-authn-exception-2401) and answer for this was > It should never go to this link for authentication. Instead, Gluu Server should go to /oxauth/login.... Pay attention on my login url **https://idp.example.com/idp/Authn/UserPassword** it is the correct url?

By Aliaksandr Samuseu staff 06 Apr 2016 at 1:45 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
What about the look of the login page when you are using Shibboleth's login flow? Is it the same as when you just directly log in to the web UI of Gluu? Can you provide a screenshot? Something strange is going on..

By Vladimir Rudenko user 06 Apr 2016 at 1:51 p.m. CDT

Copy
Vladimir Rudenko gravatar
That my login page after redirect from website [Idp Login Page](http://screencloud.net/v/kl4x) And this is login page when I use direct link [Gluu server login page](http://screencloud.net/v/n0rZ)

By Aliaksandr Samuseu staff 06 Apr 2016 at 1:53 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Got it. Definitely not right. Somehow wrong login handler is being chosen. Let me try to look into it myself..

By Aliaksandr Samuseu staff 06 Apr 2016 at 3:40 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
I've been able to reproduce it. Interesting part is it doesn't occur for my test Shibboleth SP with default settings. Here how authn request generated by it looks like: <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://sphost-shib.site:8443/Shibboleth.sso/SAML2/POST" Destination="https://alex.gluu.org/idp/profile/SAML2/Redirect/SSO" ID="_5b2ec79cb27cfdd7de1d492fdb04de78" IssueInstant="2016-04-06T20:26:52Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sphost-shib.site:8443/shibboleth</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"></samlp:NameIDPolicy></samlp:AuthnRequest> The issue is being triggered by this elements of your original request: <samlp:RequestedAuthnContext Comparison="exact"> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> and xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" (the last one defines namespace first one uses) Another intresting part is if this `saml` namespace is omitted, and `AuthnContextClassRef` is requested using `samlp` namespace, like that: <samlp:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</samlp:AuthnContextClassRef> Everything again works as it should. I'm still not sure how to evaluate it. Is it an issue of Shibboleth, of Gluu package, or mb it's not an issue at all and your SP just sends a bit malformed request?

By Aliaksandr Samuseu staff 06 Apr 2016 at 5:47 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Can't get it.. Nothings seems wrong in your original request's xml namespace definitions. Actually, the one I used (and it worked) is wrong: <samlp:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</samlp:AuthnContextClassRef> `AuthnContextClassRef` element is indeed defined within `saml` ("urn:oasis:names:tc:SAML:2.0:assertion") namespace, not `samlp` one. I may only guess that when I used wrong namespace it wasn't able to use this incorrectly defined element and resorted to some default (the same that is used for my test Shibboleth SP which does not request specific AuthnContext by default). This issue needs further investigation. Why in case of [seemingly] correct request for a specific AuthnContext it selects now deprecated legacy login handler?

By Mohib Zico Account Admin 07 Apr 2016 at 4:29 a.m. CDT

Copy
Mohib Zico gravatar
>> After request I go to the authentication page https://idp.example.com/idp/Authn/UserPassword This is wrong. Gluu Server use oxAuth for authentication, you are calling Shibboleth login handler from SP.

By Vladimir Rudenko user 08 Apr 2016 at 9:08 a.m. CDT

Copy
Vladimir Rudenko gravatar
Hi @mohib zico Thanks, I understand that, but what about ** AuthnContextClassRef** in request? I removed **RequestedAuthnContext** from request and it's seems all works correct.

By Mohib Zico Account Admin 08 Apr 2016 at 9:27 a.m. CDT

Copy
Mohib Zico gravatar
We do not recommend our users to modify any configuration file by hand. Gluu Server should work flawlessly without any problem in default setting.

By Aliaksandr Samuseu staff 08 Apr 2016 at 11:25 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Vladimir. I still haven't had opportunity to investigate it. It's hard to tell whether the problem is with Shibboleth itself, or with default configuration Shibboleth module uses in Gluu. Please omit any specific requests for AuthnContext for now as workaround. I'll let you know about results soon.

Post an answer