We are trying to implement the SAML SSO in our multiple applications but we have one specific scenario, If user is logged in into the App A using SAML SSO through the browser and then we wanted to authenticate same user to App B but from backend service using HTTP post call (non-browser), this we need to fetch some data from App B. So, is there any option available to achieve this? like getting the okta session Id in the backend & using that session Id performing the authentication in App B without the browser interaction. We don’t want to use the SAML to OAuth2 bridge as it will need extra configuration & setup also.
Any pointer to this will help us a lot. Thank you in advance.
More information about App B is required. Is this an interactive application the user is using but not browser based, or is it actually some sort of Web service (an API) that other applications fetch data from?
Thank you @jmussman for replying on the question. App B is also an web application added in Okta under same Okta Org. In one of the screen of App “A” we wanted to show the data fetched from App B, so for that purpose we required to authenticate the same logged in user in App B but this authentication we wanted to do from backend service (non-browser). I hope this info will be helpful. Thank you.
If I understand this correctly, App A and App B may be both reached by a user. In this instance though, I believe you are saying that App A may also make a direct request via HTTP to App B. It does not really matter if the return is HTML, JSON, whatever; in this case App B is functioning as a web service for App A. But, App B needs to have a SAML assertion for the user to understand the constraints under which it is to provide that data. Is this correct?
Assuming the answer is “yes”, there are two possible solutions. The first may require a modification to App B: have App A forward the SAML assertion it received to App B along with the request, and make App B accept that assertion with the App A SP entity ID (the audience). The assertion defines the user the request is made on behalf of. Notice this assertion is not landing at the SP Login URL (the assertion consumer service), it lands at the endpoint the for the request. Possession of the assertion acts as assurance the application can make the request on behalf of the user. Of course an assertion could be hijacked, so some other means of proving the authenticity of App A may be desired (source IP address, signing the request with a private key only App A knows, etc.). This is how we made many web services work before Open Authorization came along.
The second option may be easier but may require more modification, and has been my preferred solution in the past. Make both applications (and probably others too) use a shared session manager. Whichever app the user lands at first requests a SAML assertion and the user is authorized. That assertion can go into the shared session data if you want, or just user information (like their ID). When App A makes the call to App B, pass the session cookie that App A has for the user. That session is valid in App B too, so it can pull the user information from the session and proceed. This solution eliminates the need to provide assurance of App A, since it occurs through the session manager. You will find that many application environments (Microsoft .NET, Spring, etc.) offer shared session management for clustered applications.