[JIRA] Resolved: (SSPCPP-422) using requireSessionWith uses existing session, not specified session

Scott Cantor (JIRA) noreply at shibboleth.net
Thu Feb 16 21:12:38 GMT 2012


     [ https://issues.shibboleth.net/jira/browse/SSPCPP-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Cantor resolved SSPCPP-422.
---------------------------------

    Resolution: Invalid

> using requireSessionWith uses existing session, not specified session
> ---------------------------------------------------------------------
>
>                 Key: SSPCPP-422
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-422
>             Project: Shibboleth SP - C++
>          Issue Type: Bug
>          Components: Session Initiation
>    Affects Versions: 2.4.3
>            Reporter: uq0ofilvhhxxo3dxpt6ctyhi/qa=@https://login.wisc.edu/idp/shibboleth
>            Assignee: Scott Cantor
>            Priority: Critical
>              Labels: Session
>
> If your access requirement (say, from a .htaccess file) sets the requireSessionWith to a specific session, and no session exists, then the SP correctly initiates a new session. However, if you have an active session, and the .htaccess file specifies a session that is different from the current session, then the wrong session is used.
> There is no check done to make sure the current session is the one specified.
> http://svn.shibboleth.net/view/cpp-sp/trunk/shibsp/ServiceProvider.cpp?view=markup
> About line 219.  After checking for a session to exist, and one does, then the code just assumes that the session that exists is the one that was specified. It does NOT check to make sure the session specified is the correct session.
> I'd assert that a check to make sure the current session is the one that was requested is needed in the code.
> use case example:
> site https://host/app1/test/  has a .htaccess that has ShibRequireSessionWith app1
> same site, but https://host/app1/test/moresecure/  has a .htaccess that has a ShibRequireSessionWith app2
> If you first go to https://host/app1/test/ and authenticate, and then go to https://host/app1/test/moresecure/, the SP sees that there is an existing session and passes it on, it does not initiate a session for app2.
> app1 and app2 could go against 2 different IDPs, or maybe app2 has a higher authentication requirement (2-factor). 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the commits mailing list