Bug 1362293 - [GSS] (6.4.z) SAML2LogoutHandler is not handling PicketLinkSP/LogOutResponseLocation attribute properly
Summary: [GSS] (6.4.z) SAML2LogoutHandler is not handling PicketLinkSP/LogOutResponseL...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: PicketLink
Version: 6.4.8
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: CR1
: EAP 6.4.11
Assignee: Peter Palaga
QA Contact: Josef Cacek
URL:
Whiteboard:
Depends On:
Blocks: eap6411-payload 1362250 1362295
TreeView+ depends on / blocked
 
Reported: 2016-08-01 20:36 UTC by dhorton
Modified: 2019-11-14 08:51 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-01-17 13:13:57 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
employee.war (215.29 KB, application/zip)
2016-08-01 20:48 UTC, dhorton 		no flags Details
sales-post.war (180.29 KB, application/zip)
2016-08-01 20:49 UTC, dhorton 		no flags Details
idp.war (163.81 KB, application/zip)
2016-08-01 20:50 UTC, dhorton 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBEAP-4422 0 Major Verified [GSS](7.0.z) PLINK-738 - SAML2LogoutHandler is not handling PicketLinkSP/LogOutResponseLocation attribute properly 2017-04-07 11:58:12 UTC
Red Hat Issue Tracker PLINK-738 0 Major Open SAML2LogoutHandler is not handling PicketLinkSP/LogOutResponseLocation attribute properly 2017-04-07 11:58:12 UTC

Description dhorton 2016-08-01 20:36:38 UTC 
Description of problem:

When the "LogOutResponseLocation" is configured, the SAML2LogoutHandler correctly uses this value as the Destination when the SP generates  a LogoutResponse.  However, the LogOutResponseLocation" is not getting used during the HTTP POST so that LogoutResponse is getting sent to the wrong IDP url.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  Configure and deploy an idp, sales-post and employee applications
2.  Configure the "LogOutResponseLocation" in the employee.war/picketlink.xml
3.  Log into the sales-post application
4.  Hit the employee application
5.  Click on the GLO logout link in the sales-post



Expected results:

The employee.war should generate a LogoutResponse that has a "Destination" that matches the "LogOutResponseLocation".  This LogoutResponse should be sent to the same url that is specified in the LogOutResponseLocation". 


Actual results:

The LogoutResponse is not sent to the same url that is specified in the LogOutResponseLocation.


Additional info:
Comment 1 dhorton 2016-08-01 20:48:18 UTC 
Created attachment 1186537 [details]
employee.war
Comment 2 dhorton 2016-08-01 20:49:02 UTC 
Created attachment 1186538 [details]
sales-post.war
Comment 3 dhorton 2016-08-01 20:50:03 UTC 
Created attachment 1186539 [details]
idp.war
Comment 4 dhorton 2016-08-01 20:51:31 UTC 
Attached applications required to reproduce the issue.

Here is the 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>
Comment 8 Ivo Hradek 2016-10-06 10:53:01 UTC 
Verified with EAP 6.4.11.CP.CR1;
Comment 9 Petr Penicka 2017-01-17 13:13:57 UTC 
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.
Comment 10 Petr Penicka 2017-01-17 13:15:22 UTC 
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.
Note You need to log in before you can comment on or make changes to this bug.