问题
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://dev-305397.oktapreview.com/app/mncdev305397_memberapp_1/exk6jc1rntqWvSkWD0h7/sso/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
回答1:
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.
回答2:
One solution to have the SAML User Authn Context propagation is by using IdP-Proxy.
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.
来源：https://stackoverflow.com/questions/38582809/propagate-saml-assertion-response-security-context-to-downstream-services-apps