I am having a problem with a system I am building. I have successfully implemented a SP initiated SSO system. However, the issue arises when considering that this system has multiple unique and fully segregated Service Providers that must be capable of interacting and exchanging data. When one SP (SP1) needs to communicate to another SP (SP2), they need to be able to seamlessly transition while remaining secure. Thus, I assume they need to be able to assert or share SAML data.
For instance, a user tries to access the system via SP1 and is redirected to the IdP. The user authenticates against the IdP which will then assert via http post back to SP1. The user now performs a series of tasks on SP1 which eventually require data transmission or a browser redirect to SP2. SP2 is unaware that SP1 had successfully authenticated the user and received a SAML response from the IdP. This is where my problem arises. I need to implement a mechanism that will allow SP2 to become aware of the user’s status on SP1. More generally, I need to allow any service provider in a set of service providers to make assertions to one another about the status of a user. However, I cannot find documentation on the “official” way to accomplish this task.
I have thought of multiple solutions to the problem but I doubt that any of them are “official” in the least.
One would be persisting a list of SAML assertions on the IdP which can be referenced by guid. Then passing a link from SP1 to SP2 which would reference a controller action and guid that would allow the IdP to re-assert data to SP2. This seems slow and convoluted.
Two would be persisting the SAML response somehow after the response is received on SP1 and somehow passing the data to SP2 whenever a user is redirected.
I may be over-thinking and over complicating this process. I may need to move to an IdP initiated SSO based solution. I may be over looking something in the documentation.
If anyone could shed any light on this topic, it would be appreciated. I will be glad to provide any additional information about the subject.
If you control the IdP (in a sense that you can implement something extra at the IdP side) I would think of persisting some information at the IdP side upon issuing SAML tokens and then, append the information to the SAML token.
Suppose SP1 logs in by redirecting to the IdP. You store this information (cookie, session). Then SP2 logs in by redirecting to the IdP. If this is the same browser session then the information is still there, at the IdP side, available just because you have previously presisted it (cookie, session). You can then use this information to issue any assertions to the SP2.
I don’t quite get why you would have to store this information to be referenced by guid.
Although the above idea works only in the order your services contact the IdP (SP1 has no information; SP2 has information on SP1; SP3 has information on SP1 and SP2 but then SP1 still has no information on SP2 and SP3 since it won’t initiate another conversation with the IdP as it is already authenticated), I think you can easily eliminate this limitation by letting your services DROP the authentication information so that the next contact with your service requires it to initiate the conversation with the IdP.
For example, SP1 has no information, SP2 has information on SP1 but then, SP1 wants to get the information on SP2. To do so, SP1 “signs off” locally, so that it goes to the IdP and get the information on SP2 (and any other signed in parties).