Description of problem: IDP initiated (unsolicited) responses should not contain InResponseTo attributes From saml-profiles-2.0-os.pdf: 4.1.5 Unsolicited Responses An identity provider MAY initiate this profile by delivering an unsolicited <Response> message to a service provider. An unsolicited <Response> MUST NOT contain an InResponseTo attribute, nor should any bearer <SubjectConfirmationData> elements contain one. If metadata as specified in [SAMLMeta] is used, the <Response> or artifact SHOULD be delivered to the <md:AssertionConsumerService> endpoint of the service provider designated as the default.
To reproduce: - deploy idp.war and employee.war - login to IDP - http://localhost:8080/idp/ - trigger the SAMLv2 unsolicited response by going to http://localhost:8080/idp/index.html?TARGET=http://localhost:8080/employee/&SAML_VERSION=2.0 - view the SAML request that gets sent to the employee application - there should not be an InResponseTo attribute Required security-domain configuration: <security-domain name="idp" cache-type="default"> <authentication> <login-module code="UsersRoles" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> </login-module> </authentication> </security-domain> <security-domain name="sp" cache-type="default"> <authentication> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2LoginModule" flag="required"/> </authentication> </security-domain>
Verified with EAP 6.4.10.CP.CR2
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.