Clash Royale CLAN TAG

Consume Saml Response from external identity provider

I am having trouble configuring my application to consume the SAML response from an external identity provider (in this case, OneLogin). My application has a javascript (angular5) front-end and .NET back-end.

Here is our current work-flow when using our own identity provider and service provider.

Now a customer has requested we integrate their external identity provider using OneLogin. Here is what I understand to be the new workflow.

Currently, all communication between our angular front-end (client) and .NET back-end (server) is initiated by the client. What I really need is for the client to receive that SAML response form data that is posted by OneLogin, so that I can initiate authorization with our service provider and receive the appropriate response in the client, but from what I understand I won't be able to consume the Form Data client side. I was hoping I could have the external identity provider redirect to a page on our front end and encode that saml response as a query parameter, but I am not seeing any way to do that.

I feel like there is something I am missing, but all the OneLogin examples seem to be the OneLogin identity provider communicating with a server side service provider and no mention of the client side. I could use some help better understanding what I need to do to accomplish my goal of informing the client that the user is authenticated and authorized.

2 Answers
2

What you describe with OneLogin is the SAML2 Web Browser SSO profile. As you see, it's all done through the browser. The user gets redirected from the client to the IdP, where they login. The IdP then POSTs a SAMLResponse to your Attribute Consumer Service (ACS) URL at your back end. It's the ACS's job to decode the SAMLResponse and parse the SAML2 attributes contained within it. It can create a new session at that point if required.

At this point the back end now knows who the user is. So you can initiate another redirect to send the browser to another URL with a parameter that lets the client know it has to retrieve user details from the back end. Perhaps some sort of /sso?token=something URL. The client side can then ask the back end to return JSON perhaps that contains the user information referenced by token, i.e. a session of some sort the back end has created once the attributes have been verfied.

/sso?token=something

token

Our team needs to perform this exact scenario. We are also using an Angular Front-end and a .NET API Back-end. I am still a little confused as to how you got this to work. At what point does the Front-end know to redirect? Are you sending another SAML request to the IdP from the Back-end after receiving the SAML response that tells it to redirect to your Angular Front-end URL? Or does the browser just automatically handle the redirect to your Front-end URL? Also what are you returning with redirect token? I feel like there could be some security concerns there if you are just passing back an arbitrary token that anyone could copy out of your URL /sso?token=something and then authenticate via your API.

Thanks in advance!

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.