Propagate SAML Assertion Response/Security Context to downstream Services/Apps

Asked 26/7, 2016 at 6:47 Answered 27/7, 2016 at 12:45

spring-security saml-2.0 spring-saml federated-identity okta

We have multiple services in our environment.

There are scenarios where we want the user to auto-login/silently login to one or more participating services without being challenged by the Identity Provider for credentials or communicating with the Identity Provider after the first successful login from one service.

For Eg, we have a front-end UI App which we want to be authenticated using Spring Security SAML. And when the UI App communicates to back-end services we want the security context/assertion response to be propagated automatically to subsequent service calls.

Perhaps, the invoked services/app can validate the Assertion Response accordingly and allow access to their services/applications without having the all the services/apps to communicate directly with Identity Provider every time they need to be accessed.

Is there a way to propagate the SAML Assertion response obtained after successful authentication with Identity provider from one app/service to other downstream apps/services which are being invoked from the SAML authenticated app/service.

I tried to register 2 apps with Identity Provider and then authenticated one with IdP successfully, but am not not able access the other App successfully from the first one. I get an error message when I use Spring's RestTemplate to hit the service as below.

I am not sure if all downstream apps/services should be registered with IdP or not.

I get an error message as below in the first app after it has successfully authenticated with Idp and when it is trying to invoke another app which is also secured with Idp.

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
    <head>
        </head>
    <body onload="document.forms[0].submit()">
        <noscript>
            <p>
                <strong>Note:</strong> Since your browser does not support JavaScript,
                you must press the Continue button once to proceed.
            </p>
        </noscript>
        
        <form action="https&#x3a;&#x2f;&#x2f;dev-305397.oktapreview.com&#x2f;app&#x2f;mncdev305397_memberapp_1&#x2f;exk6jc1rntqWvSkWD0h7&#x2f;sso&#x2f;saml" method="post">
            <div>
                                
                <input type="hidden" name="SAMLRequest" value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJwOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1sMnA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCIgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPSJodHRwOi8vbG9jYWxob3N0OjQwODAvc2FtbC9TU08iIERlc3RpbmF0aW9uPSJodHRwczovL2Rldi0zMDUzOTcub2t0YXByZXZpZXcuY29tL2FwcC9tbmNkZXYzMDUzOTdfbWVtYmVyYXBwXzEvZXhrNmpjMXJudHFXdlNrV0QwaDcvc3NvL3NhbWwiIEZvcmNlQXV0aG49ImZhbHNlIiBJRD0iYTMzMzI4MjgzNTBmMmlkNDFoM2QxYjhiYjMwOWM2NCIgSXNQYXNzaXZlPSJmYWxzZSIgSXNzdWVJbnN0YW50PSIyMDE2LTA3LTI2VDA2OjI4OjI0LjcxNFoiIFByb3RvY29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdzOkhUVFAtUE9TVCIgVmVyc2lvbj0iMi4wIj48c2FtbDI6SXNzdWVyIHhtbG5zOnNhbWwyPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj51cm46dGVzdDptZW1iZXI6cmVhZHl1c2VyPC9zYW1sMjpJc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8+PGRzOkNhbm9uaWNhbGl6YXRpb25NZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48ZHM6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8+PGRzOlJlZmVyZW5jZSBVUkk9IiNhMzMzMjgyODM1MGYyaWQ0MWgzZDFiOGJiMzA5YzY0Ij48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PC9kczpUcmFuc2Zvcm1zPjxkczpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc2hhMSIvPjxkczpEaWdlc3RWYWx1ZT5IZ2ZRcm9pdUpRZFRqWS9uN1VENnJQSythazQ9PC9kczpEaWdlc3RWYWx1ZT48L2RzOlJlZmVyZW5jZT48L2RzOlNpZ25lZEluZm8+PGRzOlNpZ25hdHVyZVZhbHVlPkFGYUxJRDJicnRmQXNBbzY5RzhYcVdXbFVDSzByL3NxZXM1dlMvRThRUnQvL3EvdEZLR21xVm9XdFNmZnBlL3UyY0twZWFqMzNqM0NodzNGc0xkbzBtZ1JQYlU2ZFVGTk9BNkVYVEYyeEgzbXdYY1M4VUNRem10bnZoY0N6QUlDS0pSM3R0ZU83OWZiTisrZU4vYTQ0a1VoN2pydVZINUFBWmtVNTI4RHNCMkwvOTZnYzJKVmFkUlA3bUVEc0ZleTFPUmhmOXpUTWswZHZsSnpIRFNFd3JCOXZuWkhsZlEzSmNmZ05PYmIvNlJNaW9yRXJUK1l1NU5jOW41aC9iRkF1Vyt6SzNWcTg4WWZ1ZzNyeEsxbVZnMjM1U2VGSXJtRXd2aVBJTkkwNmFxNmlUaTVSOHo3MFdoN2l5c1BqUnh3bit5YVpkZ2dEUXhMbFY2NUlVOFI1UT09PC9kczpTaWduYXR1cmVWYWx1ZT48ZHM6S2V5SW5mbz48ZHM6WDUwOURhdGE+PGRzOlg1MDlDZXJ0aWZpY2F0ZT5NSUlEVWpDQ0FqcWdBd0lCQWdJRVVPTElRVEFOQmdrcWhraUc5dzBCQVFVRkFEQnJNUXN3Q1FZRFZRUUdFd0pHU1RFUU1BNEdBMVVFDQpDQk1IVlhWemFXMWhZVEVSTUE4R0ExVUVCeE1JU0dWc2MybHVhMmt4R0RBV0JnTlZCQW9URDFKTk5TQlRiMlowZDJGeVpTQlBlVEVNDQpNQW9HQTFVRUN3d0RVaVpFTVE4d0RRWURWUVFERXdaaGNHOXNiRzh3SGhjTk1UTXdNVEF4TVRFeU9EQXhXaGNOTWpJeE1qTXdNVEV5DQpPREF4V2pCck1Rc3dDUVlEVlFRR0V3SkdTVEVRTUE0R0ExVUVDQk1IVlhWemFXMWhZVEVSTUE4R0ExVUVCeE1JU0dWc2MybHVhMmt4DQpHREFXQmdOVkJBb1REMUpOTlNCVGIyWjBkMkZ5WlNCUGVURU1NQW9HQTFVRUN3d0RVaVpFTVE4d0RRWURWUVFERXdaaGNHOXNiRzh3DQpnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDWHFQMHdxTDJBaTFoYWVUajBhbHdzTGFmaHJEdFV0MDBFDQo1eGM3a2REN1BJU1JBMjcwWm1wWU1CNFcyNFVrMlFrdXdhQnA2ZEkveVJkVXZQZk9UNDVZWnJxSXhNZTI0NTFQQVFXdEVLV0Y1WjEzDQpGMEo0L2xCNzFUdHJ6eUg5NFJucVNIWEZmdlJOOEVZL3J6dUV6cnBackhkdE5zOUxSeUxxY1JUWE1NTzR6N1FnaEJ1eGgzSzVndTdLDQpxeHBIeDZObzgzV05aajRCM2d2V0xSV3YwNW5iWGgvRjlZTWVRQ2xUWDFpQk5BaExReFdod1hNS0I0dTFpUFEvS1NhYWwzUjI2cE9ODQpVVW11MXFWdFUxcXVRb3pTVFBEOEh2c0RxR0cxOXYyKy9OM3VmNWRSWXR2RVBmd1hOM3dJWSsvUjkzdkJBNmxubDVuVGN0WklSc3lnDQowR3Y1QWdNQkFBRXdEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRlF3QUFZVWpzbzFWd2pEYzJreXBLL1JSY0I4Yk1BVVVJRzBoTEdMDQo4Mkl2bktvdUdpeEdxQWNVTHdRS0l2VHM2dUdtbGdiU0c2R241Uk9iMm1sQnp0WHFRNDl6UnZpNXFXTlJ0dGlyNmV5cXdSRkdPTTZBDQo4cnhqM0poeGkyVmIvTUpuN1h6ZVZISEx6QTFzVjVod2wvMlBMbmFMMmg5V3lHOVF3QmJ3dG1rTUVxVXQvZGdpeEtiMVJ2YnkvdEJ1DQpSb2dXZ1BPTk5TQUNpVytaNW84VWRBT3FOTVpRb3pEL2kxZ09qQlhvRjBGNU9rc2pRTjd4b1FaTGo5eFhlZnhDRlE2OUZQY0ZEZUVXDQpiSHdTb0J5NWhMUE5BTGFFVW9hNXpQRHdsaXh3UmpGUVRjNVhYYVJwZ0lqeS8yZ3NMOCtZNVFSaHlYbkxxZ082N0JsTFlXL0d1SEU9PC9kczpYNTA5Q2VydGlmaWNhdGU+PC9kczpYNTA5RGF0YT48L2RzOktleUluZm8+PC9kczpTaWduYXR1cmU+PC9zYW1sMnA6QXV0aG5SZXF1ZXN0Pg=="/>                
                                
            </div>
            <noscript>
                <div>
                    <input type="submit" value="Continue"/>
                </div>
            </noscript>
        </form>
            </body>
</html>

I am using okta as the Identity Provider for my sample application.

From the error I see it is asking us to make a AuthN request to the Identity provider as it is not done directly from the browser but through code.

Can someone help me on the right way to approach this problem, so that I can successfully authenticate with one app (SP) and pass the security context/assertion response to subsequent apps/services which are involved in that flow.

Thanks,

suser

Prestige answered 26/7, 2016 at 6:47 Comment(3)

Are your apps on the same or different domains? i.e. app.company.com, app2.company.com or app.com app2.com? Are you using stateless or session based security in your apps? – Bid 26/7, 2016 at 18:26

Apps would be in the same domain. We are using resource based services so we want stateless security in the apps. – Prestige 27/7, 2016 at 11:48

@HelloUser i'm having a similar situation. could you please let us know which approach you decide? – Hatten 15/7, 2020 at 9:1

One solution to have the SAML User Authn Context propagation is by using IdP-Proxy (chain federation).

Okta-IdP <---> Your IdP-Proxy <---> Your SP-Apps

IdP-Proxy is a SAML-to-SAML gateway that sits between an IdP and an SP (as shown above). IdP-Proxy must have an SP component (so it can talk to the Okta-IdP) and it must also have an IdP component (so it can talk to the your SP-Apps).

You can configure your IdP-Proxy with Okta IdP, then configure N-number of SP-apps to your IdP-Proxy and it can talk to Okta-IdP directly to authenticate user. Then Okta send SAML Assertion to IdP-Proxy, IdP-Proxy verifies it, generate a new SAML Assertion particular to the requested SP-App and send that assertion across to the requested SP-App.

Check this for more info.

Agretha answered 26/7, 2016 at 19:15 Comment(5)

Thanks for your suggestion. But, In my case I have only one IdP which is to be shared with all SP-Apps. Wouldn't the IdP-Proxy make sense only when connecting multiple IdP's with multiple SP's. Moreover is it an IdP agnostic solution, I mean can it be used with any IdP other than Okta. Can you please provide more details on how I can use the IdP proxy with okta. The link you have shared is more with using F5, but not sure if we need this in my scenario. – Prestige 27/7, 2016 at 5:41

Yes, IdP-Proxy can be configured with multiple IdPs or with single IdP (as mentioned above). Also, SAML is a protocol specification, which is obviously agnostic and could be implemented by any company, whether it can be Okta or any other X company. That link is for reference purpose only (now I changed to generic IdP-proxy example). The answer I suggested is one solution you can consider. There could be other solutions too. – Agretha 27/7, 2016 at 6:26

Solution looks logically correct, but doesn't sound practically feasible! Consider Multiple systems federating with same IdP. Web App wants to establish backend (non-browser) connections to - say SAP. Here SAP has already registered as SP inside the same IdP. Why would SAP rely on the Assertion from another IdP (proxy IdP)? Many low code platforms provide ready to use SAML connector. There is no scope to make change there. – Scalf 5/5, 2021 at 9:12

@BhushanKarmarkar : SAML is primarily used for web-browser authentication and if non-browser (SAP) requires authentication within an SP, it's a responsibility of SP to provide to the authentication data to SAP and not SAML/IdP (Okta) and that is out of scope of this particular integration. Also, this particular integration I proposed is called chain-federation which is predominantly used by enterprises. – Agretha 5/5, 2021 at 20:48

@Agretha Thanks for putting some light. Yes I did some reading about the SAML proxy IdP. Yes looks like its an established solution and many enterprise use it. However, my only point is - it is only useful for apps under the same deployment ownership. Problem here is - as the web app and SAP uses same IdP, it is a fair expectation from the customer to have the SSO between two SPs. There are configurations of "secondary IdP" in some SAP systems. but as I said, scalability and feasibility are the main concerns. – Scalf 7/5, 2021 at 9:26

What I think you're looking for is a way to have a user login to any of the apps using the Okta IDP and be able to navigate to any of the others without being prompted for credentials again. Trying to send the assertion intended for one SP to another is not going to work. The signed SAML request includes where the request came from and where it's intended to go. You'd have to disable that portion of the security in order to get it to work and it would ultimately compromise the security of your applications.

You could have a single app configured with SAML that can act as the entry point. This project handles the SAML portion and could be extended to allow users to login to other apps without being prompted for credentials by combining it with JWT and cookies.

This can be accomplished through cookies issues to your domain that will be included in each subsequent request. This project is an example of stateless security that also uses cookies to allow the user to close the tab, and navigate back to the app and still be logged in. In theory, you could extend this behavior to multiple apps if the cookie is issued correctly, i.e. *.example.com If the other apps are configured to use the same cookie, the behaviour you should see is what I think you're looking for.

Hope this helps.

Bid answered 27/7, 2016 at 12:45 Comment(0)

Recommended topics

Hot tags