By: Kishore Basa user 15 Feb 2016 at 9:27 a.m. CST

9 Responses
Kishore Basa gravatar
Hello , I have setup trust between Gluu IDP and ADFS (Service Provider). It works as expected for few applications added in ADFS. I keep getting the below error, when trying to access a specific SAML application configured in ADFS. > " An error occurred while processing your request. Please contact your helpdesk or user ID office for assistance. > This service requires cookies. Please ensure cookies are enabled in your browser, then go back to your desired resource and try to login again. > Use of your browser's back button may cause specific errors that can be resolved by going back to your desired resource and trying to login again. > If you think you were sent here in error, please contact technical support > Error Message: Error decoding authentication request message" When i verify the SAML response , there is an error sent from Gluu to ADFS ** samlp:Status samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" samlp:StatusCode samlp:Status** Can someone please help me find the fix for this issue.. Thank you Kbasa

By Michael Schwartz Account Admin 15 Feb 2016 at 9:49 a.m. CST

Michael Schwartz gravatar
I think you're going to have to research the Shibboleth IDP mailing lists to see if this is a configuration issue. You can post the idp log files (/opt/idp/logs) and the relying-party.xml config snippet, and that may help.

By Kishore Basa user 15 Feb 2016 at 10:17 a.m. CST

Kishore Basa gravatar
Here is error trace from the idp-process.log http://pastebin.com/2PbfVSsd **And the relying-party.xml config snippet is ** <?xml version="1.0" encoding="UTF-8"?> <!-- This file is an EXAMPLE configuration file. This file specifies relying party dependent configurations for the IdP, for example, whether SAML assertions to a particular relying party should be signed. It also includes metadata provider and credential definitions used when answering requests to a relying party. --> <rp:RelyingPartyGroup xmlns:rp="urn:mace:shibboleth:2.0:relying-party" xmlns:saml="urn:mace:shibboleth:2.0:relying-party:saml" xmlns:metadata="urn:mace:shibboleth:2.0:metadata" xmlns:resource="urn:mace:shibboleth:2.0:resource" xmlns:security="urn:mace:shibboleth:2.0:security" xmlns:samlsec="urn:mace:shibboleth:2.0:security:saml" xmlns:samlmd="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:relying-party classpath:/schema/shibboleth-2.0-relying-party.xsd urn:mace:shibboleth:2.0:relying-party:saml classpath:/schema/shibboleth-2.0-relying-party-saml.xsd urn:mace:shibboleth:2.0:metadata classpath:/schema/shibboleth-2.0-metadata.xsd urn:mace:shibboleth:2.0:resource classpath:/schema/shibboleth-2.0-resource.xsd urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0-security.xsd urn:mace:shibboleth:2.0:security:saml classpath:/schema/shibboleth-2.0-security-policy-saml.xsd urn:oasis:names:tc:SAML:2.0:metadata classpath:/schema/saml-schema-metadata-2.0.xsd"> <rp:AnonymousRelyingParty provider="idp" ></rp:AnonymousRelyingParty> <rp:DefaultRelyingParty provider="https://guestID-dev.weill.cornell.edu/idp/shibboleth" > <!-- defaultSigningCredentialRef="IdPCredential" Each attribute in these profiles configuration is set to its default value, that is, the values that would be in effect if those attributes were not present. We list them here so that people are aware of them (since they seem reluctant to read the documentation). --> <rp:ProfileConfiguration xsi:type="saml:ShibbolethSSOProfile" includeAttributeStatement="false" assertionLifetime="PT5M" signResponses="conditional" signAssertions="never" ></rp:ProfileConfiguration> <rp:ProfileConfiguration xsi:type="saml:SAML1AttributeQueryProfile" assertionLifetime="PT5M" signResponses="conditional" signAssertions="never" ></rp:ProfileConfiguration> <rp:ProfileConfiguration xsi:type="saml:SAML1ArtifactResolutionProfile" signResponses="conditional" signAssertions="never" ></rp:ProfileConfiguration> <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="conditional" signAssertions="never" encryptAssertions="conditional" encryptNameIds="never" ></rp:ProfileConfiguration> <rp:ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="conditional" signAssertions="never" encryptAssertions="conditional" encryptNameIds="never" ></rp:ProfileConfiguration> <rp:ProfileConfiguration xsi:type="saml:SAML2ArtifactResolutionProfile" signResponses="conditional" signAssertions="never" encryptAssertions="conditional" encryptNameIds="never"></rp:ProfileConfiguration> </rp:DefaultRelyingParty> <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:ChainingMetadataProvider"> </metadata:MetadataProvider> <!-- DO NOT EDIT BELOW THIS POINT --> <!-- The following trust engines and rules control every aspect of security related to incoming messages. Trust engines evaluate various tokens (like digital signatures) for trust worthiness while the security policies establish a set of checks that an incoming message must pass in order to be considered secure. Naturally some of these checks require the validation of the tokens evaluated by the trust engines and so you'll see some rules that reference the declared trust engines. --> <security:TrustEngine id="shibboleth.SignatureTrustEngine" xsi:type="security:SignatureChaining"> <security:TrustEngine id="shibboleth.SignatureMetadataExplicitKeyTrustEngine" xsi:type="security:MetadataExplicitKeySignature" metadataProviderRef="ShibbolethMetadata" ></security:TrustEngine> <security:TrustEngine id="shibboleth.SignatureMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXSignature" metadataProviderRef="ShibbolethMetadata" ></security:TrustEngine> </security:TrustEngine> <security:TrustEngine id="shibboleth.CredentialTrustEngine" xsi:type="security:Chaining"> <security:TrustEngine id="shibboleth.CredentialMetadataExplictKeyTrustEngine" xsi:type="security:MetadataExplicitKey" metadataProviderRef="ShibbolethMetadata" ></security:TrustEngine> <security:TrustEngine id="shibboleth.CredentialMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXX509Credential" metadataProviderRef="ShibbolethMetadata" ></security:TrustEngine> </security:TrustEngine> <security:SecurityPolicy id="shibboleth.ShibbolethSSOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:IssueInstant" required="false"></security:Rule> <security:Rule xsi:type="samlsec:MandatoryIssuer"></security:Rule> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML1AttributeQuerySecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"></security:Rule> <security:Rule xsi:type="samlsec:IssueInstant"></security:Rule> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:MandatoryIssuer"></security:Rule> <security:Rule xsi:type="security:MandatoryMessageAuthentication" ></security:Rule> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML1ArtifactResolutionSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"></security:Rule> <security:Rule xsi:type="samlsec:IssueInstant"></security:Rule> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:MandatoryIssuer"></security:Rule> <security:Rule xsi:type="security:MandatoryMessageAuthentication" ></security:Rule> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2SSOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"></security:Rule> <security:Rule xsi:type="samlsec:IssueInstant"></security:Rule> <security:Rule xsi:type="samlsec:SAML2AuthnRequestsSigned"></security:Rule> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:MandatoryIssuer"></security:Rule> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2AttributeQuerySecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"></security:Rule> <security:Rule xsi:type="samlsec:IssueInstant"></security:Rule> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:MandatoryIssuer"></security:Rule> <security:Rule xsi:type="security:MandatoryMessageAuthentication" ></security:Rule> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2ArtifactResolutionSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"></security:Rule> <security:Rule xsi:type="samlsec:IssueInstant"></security:Rule> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:MandatoryIssuer"></security:Rule> <security:Rule xsi:type="security:MandatoryMessageAuthentication" ></security:Rule> </security:SecurityPolicy> <security:SecurityPolicy id="shibboleth.SAML2SLOSecurityPolicy" xsi:type="security:SecurityPolicyType"> <security:Rule xsi:type="samlsec:Replay"></security:Rule> <security:Rule xsi:type="samlsec:IssueInstant"></security:Rule> <security:Rule xsi:type="samlsec:ProtocolWithXMLSignature" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign" trustEngineRef="shibboleth.SignatureTrustEngine" ></security:Rule> <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine" ></security:Rule> <security:Rule xsi:type="samlsec:MandatoryIssuer"></security:Rule> <security:Rule xsi:type="security:MandatoryMessageAuthentication" ></security:Rule> </security:SecurityPolicy> </rp:RelyingPartyGroup>

By Kishore Basa user 16 Feb 2016 at 9:49 a.m. CST

Kishore Basa gravatar
Hello Michael, After some digging i found this issue , SP is expecting the AuthnContext to be **urn:oasis:names:tc:SAML:2.0:ac:classes:Password** But Gluu IDP is sending **<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod>** Added an entry to the handler.xml from below location and restarted the Gluu server. /opt/gluu-server-2.4.1/install/community-edition-setup/static/idp/conf/handler.xml > <!-- Login Handlers --> < ph:LoginHandler xsi:type="ph:RemoteUser"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:Unspecified</ph:AuthenticationMethod> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</ph:AuthenticationMethod> </ph:LoginHandler > <!-- Username/password login handler --> < ph:LoginHandler xsi:type="ph:UsernamePassword" jaasConfigurationLocation="file:///opt/idp/conf/login.config"> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</ph:AuthenticationMethod> </ph:LoginHandler > Still it sends the default authncontxt as PasswordProtectedTransport. Could you please guide me on changing Authentication methods in GLUU IDP. Thanks Kishore

By Aliaksandr Samuseu staff 16 Feb 2016 at 12:55 p.m. CST

Aliaksandr Samuseu gravatar
Hi, Kishore. Let met try to reproduce your issue.. Regards, Alex.

By Kishore Basa user 22 Feb 2016 at 4:07 a.m. CST

Kishore Basa gravatar
Hello Aliaksandr, Could you please let me know if you were able to replicate the issue in your environment.? Thanks Kishore.

By Aliaksandr Samuseu staff 22 Feb 2016 at 7:32 p.m. CST

Aliaksandr Samuseu gravatar
Hi, Kishore. Can't say anything helpful yet. Just one moment: to modify Shibboleth's configuration (the package that responsible for serving SAML request in Gluu) you need to modify at least Velocity templates in `/opt/tomcat/conf/shibboleth2/idp/` directory (in your case it will be file `handler.xml.vm`). When tomcat is started, they are being used to deploy configuration files in the `/opt/idp/conf` directory, from where it is loaded by Shibboleth. I'm not sure it's refreshing configuration after start, so to be sure changes are applied you should restart the tomcat service each time you modify anything in these directories. So it's quite possible that if you change just templates in `/opt/tomcat/conf/shibboleth2/idp/` and restart the service, then Shibboleth will load previous version of configuration (before tomcat will have a change to deploy updated files from templates); that's why it's better to modify files at both these directories at once, template and actual file (but be advised about significantly different syntaxes used in them!). My current tests of using your approach are showing that even when correct configuration files are modified, it still won't work: for authentication it redirects me to the page at url like `https://my.host.name/idp/Authn/UserPassword` which has old-styled (2.3.x-like) design and looks somewhat broken; it doesn't allow you to log in (I'm attaching an error trace from idp-process.log)

By Kishore Basa user 23 Feb 2016 at 6:15 a.m. CST

Kishore Basa gravatar
Hello Aliaksandr Thanks for trying this out, Hopefully we are on the same page now. I have no option to modify the Authentication parameters at Service Provider as it is linked with other IDP's , which are passing the required authn contxt to the SP. Please let me know if we are left out with any other options. Thank you. Kishore

By Michael Schwartz Account Admin 23 Feb 2016 at 3:43 p.m. CST

Michael Schwartz gravatar
This is an advanced topic. If you purchase a basic support contract, we may be able to dig in deeper to this issue. Is that an option?

By Kishore Basa user 26 Feb 2016 at 2:45 a.m. CST

Kishore Basa gravatar
Hello Michael, Thank you for help. We are still exploring the features of GLUU IDP. Support contract would be our last resort, i can say that its not an option for now atleast. Thank you, Kishore.