Unfortuantely the built in AEM SAML Utility does not support the HTTP Redirect binding (only post binding). I have to perform SAML authentication to an external IDP which has HTTP redirect for both single sign on and single logout. Because of the AEM limitation I would like to configure ADFS to handle authentication with this external IDP and somehow get AEM to talk to that ADFS (either a federation service, or maybe an RP or claims provider). Does anybody know how this could potentially be achieved? I am assuming I could leverage the SAML utility or the SSO utility/modules in AEM (sling) to connect to ADFS somehow who will be responsbile to relay or proxy the IDP response to AEM. thanks
Using OOTB SAML Authentication Handler there is an option IDP HTTP Redirect, I was able to configure SAML authentication with a redirect to ADFS and then after giving credentials, IDP was redirecting back to AEM with SAML2 response containing all the data, however, that was handled by POST Binding.
EDIT:, OK, I have just noticed that IDP HTTP Redirect option is not present in linked official documentation however on the video in this tutorial you can see it available on AEM 6.1... I do not recollect now if the POST binding is used at the end so that please check first if that might work with this option as I have used that before.
If you would need other solution, the fastest option I see is checking the default implementation of SAML Authentication Handler by decompiling (it can be done following these steps, by at the same time I am only suggesting, not recommending that!) and base on it implementing custom handler adapted to your needs.
Related
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
I am need an advice how to configure the single logout service url for SSOCIRCLE idp.
I have found the page which helped me with configurung SSO url:
https://www.ssocircle.com/en/idp-tips-tricks/ssocircle-how-to/ point 5.
For example, here is my sso:
https://idp.ssocircle.com/sso/idpssoinit?metaAlias=%2Fpublicidp&spEntityID=acc/test.com/testidp
How should I configure slo url?
Also here is some docs: https://www.ssocircle.com/en/idp-tips-tricks/public-idp-configuration/ but I cant understand what should be in url instead of: 'IDPSloPost' value.
Could anyone please suggest the solution ?
You can either trigger the single logout process from your SP sending a LogoutRequest to the endpoint as listed in http://https://www.ssocircle.com/en/idp-tips-tricks/public-idp-configuration/ (use the correct endpoint matching the binding your SP uses).
Or you can start the logout process from the IDP using the URL
https://idp.ssocircle.com/sso/IDPSloInit?metaAlias=%2Fpublicidp
Please keep in mind that SLO is much harder to achieve than SSO. All SPs must support the flow correctly otherwise the flow of redirects easily break in front channel bindings.
I'm working on a research about some new usage of SSO. Basically I'm trying to find way how to intercept SAML Request which is sent from Service Provider to Identity Provider with some kind of IdP proxy or 3rd party service, which will hold the SAML Request and will provide some additional functionality to users. The desired process could look like this:
User invokes SAML request from SP - click Login button for example
User is redirected to the 3rd party service, where is, for example, small survey(this is theoretical example)
After submitting the survey, user is redirected to the IdP and should continue with login
I have quite good experience with SimpleSAMLphp and configuring federation. But I my attempts to find some useful information about this kind of interception have failed. I add a super basic picture of the solution.(please don't laugh:) )
Does SAML support any kind of this processing? I'm open for discussion. I was also thinking to intercept the SAML after user signs in on IdP(to have redirection from IdP to 3rd part service proxy and then to SP)
Thank you for advices and your thoughts; hopefully, it's not totally stupid question
EDIT: During my research I came across technology/approach which is called IDP Proxy. Do you think that is feasible for my purpose? Basically, a SAML IdP Proxy is a bridge or gateway between a federation of SAML IdPs and a federation of SAML SPs. More about it for example here
I don't think this is possible, it's simply beyond the protocol. The SP provides a service, the IdP is responsible for user authentication. There seems to be no place for a 3rd party service between the two.
I guess you control (at least) either the SP or the IdP. Try to implement your survey (or whatever) at the provider you control.
As an alternative, you could try to implement your own IdP including a survey (or whatever) that uses the original IdP for authentication.
I'm implementing a SSO solution with SAML using OpenAM. I'm a very beginner on theses technologies and I need some clarifications.
My progress
For the moment, I have installed a Tomcat hosting OpenAM as an IdP.
Another Tomcat fits as my SP. The WebAgent is installed on it. When trying to reach a protected part of the SP, I am redirected to the IdP logging page. Once my credentials entered, I am finally redirected to the resource. That seems to work well.
My questions
My architecture is just based on a simple SSO, doesn't it ?
How do I activate the SAMLv2 ?
Does OpenAM have to be install on all servers in the circle of trust to allow SAML ? I mean, it seems natural on the IdP, but do I need to put and configure the opensso.war on the SPs ?
The choosen scenario is IdP-Initiated SSO. If the client reaches the IdP Authenticate WS, will it have the SAML assertion ?
Thanks in advance
When using agents, you are actually relying on a more proprietary SSO and not SAML. To be precise: Liberty ID-FF messages wrapped in SAML 1.1
The web agents will never talk using SAMLv2, so you will need to have some sort of SAML SP implementation (Java fedlet/.NET fedlet/SimpleSAMLPHP/Shibboleth SP/etc). To enable SAMLv2 federation you may as well follow the documentation ( http://docs.forgerock.org/en/openam/10.0.0/admin-guide/index.html#chap-federation )
If Authenticate WS means /openam/identity/authenticate REST/JAX-WS endpoint, then the answer is no, but if you correctly initiate a SAMLv2 login on the IdP (by using the idpssoinit endpoint), then the assertion will be presented to the SP, where the SP implementation can perform the necessary validations and extract the actual data out of the assertion.
I'm in the midst of finding some means (preferably through Java code) that will enable me to get the SAML assertion from the IDP (i.e. ForgeRock's OpenAM) for a Service Provider (SP) via SSO Login.
The SP have already been configured to interact with the IDP (e.g. vCloud Director --> OpenAM and vice versa) through a Web Browser (i.e. the user will be automatically redirected to the OpenAM login page upon invoking the vCloud Director login page). However, this process is only applicable through browsers (where redirection is provided) but not outside the browser.
I can't seem to find any means to perform SSO Login (by using the SAML assertion from the IDP for authentication). So far I've come across a dozen of references including the AssertionIDRequestUtil.sendAssertionIDRequestURI function from the OpenAM SSO, still, I'm not sure where to retrieve the AssertionId and SAML EntityId parameters.
Are there other means of getting the SAML assertion? Or maybe other ways to perform SSO Login?
I think the easiest way to achieve this would be:
perform authentication via REST or ClientSDK
use a Java HTTP client to kick off an IdP initiated SAML authentication flow (/openam/idpssoinit?metaAlias=/idp&spEntityID=entityID). When you send this request you need to make sure that:
the session id is part of the request as an iPlanetDirectoryPro cookie,
session upgrade won't be performed (your authcontext settings at the IdP will have a lower or equal authLevel, than the level the session was created with in the first step)