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.
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?
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.
So I'm struggling a bit with the basics of the flow of SAML. Here's the scenario I find confusing.
I have a java web application. The user is logged in. I know they want to order cookies from a 3rd party because they've clicked on the "I want chocolate chip cookies" link. I also know that "Mrs. Pillsbury Cookies Co." is a "Service Provider" because she sent me her meta-data and I've registered her with my Gluu Server (IdP). I've also sent her my IdP meta-data so we've done the whole hand-shaking thing.
My question is...how do I now send the SAMLResponse to Mrs. Pillsbury? She's given me a SOAP endpoint that is waiting for a SAMLResponse. How do I tell my Java application to get some XML from my gluu server as a SAMLReponse that I can then pass to the Pillsbury SOAP endpoint? That's the part where I'm stuck...I don't know how to get a response to forward. I can see in the metadata that there are lots of SSO endpoints
<SingleSignOnService Binding="urn:mace:shibboleth:2.0:profiles:AuthnRequest" Location="https://idp.myjavaapp.com/idp/profile/SAML2/Unsolicited/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://idp.myjavaapp.com/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://idp.myjavaapp.com/idp/profile/SAML2/POST-SimpleSign/SSO
Am I supposed to hit one of those SSO endpoints and it'll generate a response that I can then forward on to Pillsbury? Can one of you SAML experts out there get me straigtened out? Thanks in advance.
There are a few ways SAML Requests/Responses can be generated.
IdP initiated:
This is a SAML Response generated w/o a SAML request. This requires the user to login/be logged into the idP and the idP will generate a SAML Response based off the SP setup in the idp.
SP initiated:
This is usually an HTTP Redirect but can be a POST as well. This is a SAML Request Redirect/POST that gets sent to the idP based of some link or button on the SP's website.
As I understand it you have the following relationship:
Your App
\
3rd Party ordering
/
IdP Server
Your app needs to make a request to the 3rd party, but also need it to authenticate against the IdP. Yes?
Normally the process works such that the 3rd party requests the token itself. Your app shouldn't have the token intended for the 3rd party -- it should only have the token for its own app.
Usually you send whatever your app-specific request is to the 3rd party first. When they receive that bit of information they hold onto it and then make a SP-Initiated authentication request to your IdP. They will attach a bit of information as part of the auth request called relay state. This bit of information is used to reconstitute the session after the IdP responds.
Once the IdP receives the request it does whatever it needs to do to authenticate the user, and sends the token back to the 3rd party. As part of that response they also send the relay state. The 3rd party then verifies the token and sets the session as necessary, then reads the relay state and sets whatever internal state is necessary to continue the order.
You're on the right track. As the previous answers have explained, it can be done one of two ways: the SP site (Pillsbury) sends you an authentication request, or you can direct your IDP/Gluu server to send an SAML message to the SP without them prompting: "unsolicited".
In the case of the first "SP-Initiated", you just create a link to the SP site for the user's browser to follow. The user's browser hits the SP site, the SP site realizes that it needs to authenticate the user: so it creates a SAML Authentication Request to your IDP endpoint, directing the user's browser there. Then your IDP server will respond according to the metadata/relationship that you've set up with the SP site. Just as one of the other answers explained, this Authentication Request can include a RelayState parameter which will be sent back to the SP to tell them where to send the user after the SAML message had been consumed & validated. I haven't used Gluu but I believe the SP would use the second endpoint you showed in your question to do this.
In the case of the second "IDP-initiated", you need to direct the user's browser to one of the Gluu server endpoints to generate a SAML assertion, which will be POST'd back to the SP site without the SP site's prompting. This one is less used because every time the user is directed to the SP site from your site, they will be forced through the AuthN process among other reasons. I believe this is the first listed endpoint that you showed in your question.
Here's a really good explanation of IDP-initiated from Shibboleth, that should help clear this up for you: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO
Best of luck!
I have seen a similar post but that was more related to ASP. I will explain my situation below.
I am developing a SP(Relying Party) and integrating with ADFS (IDP). Since I am in the integration phase, I want ADFS to forget that I have previously authenticated so that each time I hit the ADFS endpoint (/adfs/ls) with AuthnRequest, I want it to ask for my credentials.
I believe ADFS by default, remembers clients by their remote IP/host name so clearing cookies on client machine does not help. There was a post that gave a link to logout from IDP (https:///adfs/ls/?wa=wsignout1.0&wreply=https:///adfs/ls/?wa=wsignoutcleanup1.0). The ADFS says I have been logged out but when I hit ADFS endpoint, ADFS redirects back to SP with successful AuthResponse.
Can you please tell me how to force reauthenticate/logout on ADFS or point me to the right articles?
The FederatedPassiveSignInStatus control (which should be part of VS if you've installed all the WIF stuff) will help you. Add it to your app. and clicking it will log you out of everything.
Also AD FS: How to Invoke a WS-Federation Sign-Out
Add wfresh=0 as a URL parameter.
This parameter indicates "freshness requirements".
According to the spec:
If specified, this indicates the desired maximum age of authentication specified in minutes.
Problem: an SP site xyz.com/A gets a request for a resource xyz.com/B requiring authentication. A SAML request with relay_state=xyz.com/B gets sent to the iDP. The user gets redirected to the iDP site through SAML/SSO then onto idp.com.
I want to implement a link that allows the user to cancel his request for xyz.com/B and simply return him back to where he was browsing at xyz.com/A. Because there was a SAML redirect, I can't use the referer header at idp.com to find out where the user came from. Ideally I want to send the returnURL=xyz.com/A inside my SAML request.
So the question is is there such a way?
Thanks
I'm not aware of a standard SAML way you could achieve this. You would likely need to rely on custom extensions (such as additional query string parameters) to tell the IdP where to go on cancel.
Alternatively (and not so elegant - but practical) you could use JavaScript to send the user back a couple steps in the history? E.g.:
window.history.go(-2)
The IDP can return SAML response to SP. In the SAML response, you can use Status element to indicate that the user has cancelled the authentication process. As the top-level status code, you can use urn:oasis:names:tc:SAML:2.0:Responder. You can use your own status code as the the second-level status code.