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.

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>

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

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

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

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)

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

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?

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.