Using Shibboleth SP for Authentication but not Authorization or Session Management

[Cantor, Scott]

On 1/27/15, 1:11 AM, "Spencer Gaddy" <recneps at gmail.com> wrote:



>Hi Peter thanks for the response on this, as a quick follow up I am 
>trying to determine how to establish a session of my own after the Shib 
>SP has verified a SAML assertion from an IDP. My actual application is 
>running on an entirely different server, then the SP so the application 
>is completely decoupled and will not have access to any information about 
>the authenticated individual.

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPOneMany


That doesn't work. It's not physically possible, outside of the case of 
proxying access to the application. Connecting two servers is Web SSO. 
That requires a SSO protocol. If the two servers are tightly coupled, then 
a simple protocol involving a shared secret and an HMAC over the data to 
transmit is sufficient. If you don't know how to do that safely, you'll 
create a hole in your system.

>Is there anyway to add a bit of code inside the /Shibboleth.sso/Login 
>handler that after verifying a SAML assertion from the IDP it will run my 
>piece of code that will do all the extra work I want to do in addition to 
>the standard login handle? If so could you please direct me as to where I 
>would be able to find this?

You wouldn't do that (it's in C++ and is compiled code), and that doesn't 
do what you want anyway. Any code you want to run simply lives on the 
server running the SP. That doesn't help you establish a session somewhere 
else, not by itself.

>If this is not possible would it be more feasible to add a single 
>protected resource on the SP, which after the SP verifies the SAML 
>assertion from the IDP. This code would be redirect to after the SP was 
>finished and would have access to the authenticating users information I 
>could then add some code here that does my logic and then redirects back 
>to the original resource I am protecting (which is outside the SP server).

Yes. But it's not just a redirect. It's a second protocol deployed by you 
in place of deploying SAML directly on the application server. The SP 
doesn't care what you do, but the security of that exchange is on you.

-- Scott