I am not sure but is it possible to pass entityId in AuthnStatement to Shibboleth SP? I am already sending uid in response AuthnStatement.
Suppose a request is coming to Idp from SP having entityId as https://sp.example.com/Shibboleth. After authentication, Idp should post uid as well as entityId to SP.
Let me know if this is possible or is there any way to get entityId attribute in IdP attribute-resolver.xml file.
Thanks in Advance.
Now, I know the answer and updating it so that It can help other as well.
We don't have to worry about Idp URL at SP Side as once the Shibboleth session gets established, It stores all the information like Shibboleth Idp, Authnmethod, and other released parameters into the session.
Once you hit your protected resources, it set all those attributes into headers and can be easily fetched in your application.
Eg: get Idp URL
request.getHeader("Shib-Identity-Provider")
Check here for the list of headers.
Related
We have to integrate third party SP for SSO. Our application is a wrapper in spring(not springboot) and it has authentication/authorization module calling backend service using mongo as DB.
Now the requirement is to integrate SSO SAML based SP with a third party. The third party has given docs which asks to have IDP. In the provided requirement from SP, Nameid assertion has to be persistent ,unique and opaque and can be userid of client application (our application).
I believe we have to have an IDP like SSOCircle or Okta or some open source IDP in order to integrate with SP. And I think we can write a separate springboot SAML IDP and expose api to our legacy spring for login to SP.
Flow as I understand:
User from our portal access the third party SP website or API.
Third party SP will redirect the user to our IDP to log in .They will save NameId(UUID mapping of userids or userids) at their end which they will pass as SAML request along with other assertions.
Once User is successfully logged in , our IDP will redirect the user to third party SP with success response.
My questions :
Can (or should we )we bypass IDP ? I guess this would mean we write SAML IDP on our own. Please let me know my best options or whether this is a good idea to go without IDP and write our own equivalent.If we can't, I would assume we have buy paid proprietary or use open source IDP.
Nameid (unique, persistent, opaque) assertion : This is one of SP requirement.If we have to use IDP (which I think), and it SP consumer assertion requirement is to use persistent Nameid to be passed.It should be unique, persistent and opaque . So we are thinking that UUID mapping of userids in SAML request to IDP should be OK. If we go like this, we have to store UUID mapping in DB as nameid assertion . Do we have to use just our portal userids as nameIds or UUID in DP -SP integration to satisfy requirement? Please comment what approach is right.
Nameid persistence restrictions at IDP end as well as at SP end:There is one bottleneck at our end.Our IT security team would probably not allow NameId persistent mapping UUID forever due to security concern, In that case NameId mapping will change at our end. How should be address this if we have to use UUID as nameid?
NameId provisioning : when user from our portal request to login to SP - Would it be passed to SP as login request and then SP constructs saml request and pass nameids assertions to IDP ? If yes ,what is best approach for nameids be passed to SP as login request ? If no, how will SP know what UUID to pass in SAML to IDP? How will we address this if the mapping nameid are UUIDs which could change due to security concerns? . Another thing is though nameid is mentioned is mentioned as "persistent" in requirement but in the examples of requirement doc they are showing urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified . I think thats probably a mistake in doc. [?].
Any sample SSO SAML IDP (client ) application which we can refer which is close to above 1 ) and 2)?
Can (or should we )we bypass IDP ? I guess this would mean we write SAML IDP on our own.
No, you can't. If the 3rd party acts as a SAML Service Provicer, you need to or act as a SAML Identity Provider. Building your own implementation is quite a big tasks and you may either use an SAAS-based IdP like SSO Cirle (keep in mind that your customer needs to accept where the user idenity data is stored) or deploy your own SAML IdP. There are payed products/service or free-of-charge. Open source need not mean free-of-charge , that's often misunderstood.
If you need a SAML IdP anyway, you may think of making your own app act as a SAML SP as well to leverage authentication of the IdP.
Which NameId format to use is kind of agreement. The SAML spec propose the usage of specific NameId format for specific purposes, e.g.
'transient' NameId format is meant to be used for SSO flow only.
'persistent' is meant to be used when you want to link identities of different identity silos together
The SP may use the value of the NameId value in the subject to find a user's profile or to perform auto-federation (build a profile on its side). It could also use attributes from the SAML attribute statement to achieve the same. Many SP implementations offer this.
I am trying to pass on a URL as RelayState in the SAML request from SP to IDP so that I get it back once the authentication is complete. But, I am not able to figure out how to do so. I am using sustainsys.saml2 for the saml configuration in my ASP.NET WebApi application.
Question 1: Currently, I have a URL something like this: http://example.com/tmwebapi/saml2/signin?http://www.okta.com/hgdhsg324234jhsdf. When I enter this in address bar, it redirects me to the IDP interface. How to pass the RelayState here?
Question 2: Once the RelayState is passed successfully, I want to be able to extract it in the ACS endpoint. How can I do that?
Please let me know if anyother information is required.
Thanks in advance.
Using the /Saml2/Signin endpoint it is not possible to preserve custom information across the authentication call. You can preserve a return url by adding a ReturnUrl parameter to the query string.
If you use the API instead, you can put any state you want to preserve in the AuthenticationProperties dictionary. It will then be available after the authentication is completed. This is how the ReturnUrl is implemented.
I'm looking to implement a plugin using OpenSAML for a 3rd party application that will enable the application to be treated as a SAML Service Provider, so that I can integrate it into AWS SSO.
The following image describes the SAML authentication process when the Service Provider (SP) and Identity Provider (IdP) use HTTP Artifact binding (taken from here):
After the initial authentication, the SP returns the protected resource to the user. My question relates to how subsequent requests for protected resources are processed.
With OIDC, the browser would receive a token and this would be sent to the SP for subsequent requests. The SP can inspect the token and confirm its integrity (assuming it is signed) and validity, without needing to make further calls to the IdP to re-authenticate the end-user.
With SAML, how do I achieve the same effect? How do I not have to make repeated calls to the IdP to check identity?
I suppose I could use a session, but I don't understand how I might ensure that such information is not tampered with within the client (i.e. how does the SP not have to rely on information provided by the client?). Does SAML have some sort of concept of a token that is safe for the user to store (the HTTP Artifact binding explicitly restricts the user from seeing the response from the IdP)?
What happens after the last step is not defined in the spec. You could say it's formally outside of SAML protocol. Even the last protocol-formalized step of SP supplying the resource is essentially a "do it yourself":
Section 3.4.5 (HTTP-Redirect binding):
Upon receiving the SAML response, the SAML requester returns an
arbitrary HTTP response to the user agent
Section 3.5 (HTTP-POST binding):
Upon receiving the SAML response, the SAML requester returns an
arbitrary HTTP response to the user agent
Section 3.6 (HTTP-Artifact binding):
[you can probably guess by now]
Most SPs will drop one or more cookies on the client during that last step. One of those cookies will contain a session ID or a more generic pointer that can be used to locate a session when sent back to SP. Subsequent resource "authorization" requests to SP will proceed by having the SP consult this server-side session. The session will usually hold the (authenticated) security context for this user/client.
For example, Shibboleth (built on top of OpenSAML) does so. The content of the cookie is up to the SP. It's arguable that token-based auth via e.g. local storage is more secure vs a cookie. There are pros/cons to both options and many factors specific to use case/context/technology stack impact the evaluation of risk and associated threat model.
Note: AWS SSO does not support the Artifact binding.
I am using the OneLogin SAML Test Connector as a simulated IDP with the ruby-saml gem and the supplied sample program. That's working fine.
In my real-world app, we are the SP and there are multiple identity providers, each of which will have multiple users who need to SSO to our app.
I have observed that in the sample app, my AuthnRequest does not define the user's nameID (email address) anywhere, but instead it is appended to the IDP URL in the form of a numeric id. e.g. https://app.onelogin.com/saml/metadata/5551212 where app.onelogin.com identifies the IDP and 5551212 identifies the "user". I realize that when onelogin is the IDP the "user" is actually an app id, but in our case we want it to identify an actual user, not an app.
Is it correct that the AuthnRequest does not contain a nameID element?
Should I identify the user in the IDP's URL using a numeric ID? The numeric id would have to be shared offline between the parties, and would have to be transmitted in the initiating URL. I like this approach because it doesn't expose any identifying information in the URL, e.g. an email address.
Should I identify the user by Base64-encoding the email address and appending that to the URL? This is less secure, but it might be ok since the transmission will always be encrypted with SSL. And it avoids the offline handshake and sharing a numeric ID.
AuthnRequest does not define the user's nameID (email address)
anywhere, but instead it is appended to the IDP URL in the form of a
numeric id.
This is not true, that numeric id identify internally the IdP, not the user.
Yes, check the SAML standard, saml:Subject is optional. And SAML2int profile says that AuthNRequest message MUST NOT contain a saml:Subject.
No
No
You don't need to pass user information to the IdP, you should simply send an AuthNRequest to the SSO endpoint and a form to place a username/password gonna be showed to the user (if already exists an active session this authentication is not required. Then a SAMLResponse will be send back to the SP's Assertion Consumer Service endpoint.
Correct. Check out https://www.samltool.com/base64.php to help with looking at Response attributes.
We're implementing a web SSO solution using PingFederate, with a 3rd party product that includes SAML2 out of the box.
However we're trying to work through the question of how to stop the IDP session timing out if the user is still actively using the SP.
The 3rd party product supports requesting an empty resource on the IDP side, with the intention that this URL would result in the IDP session being extended.
I can't see anything in PingFederate that supports anything like this. Does anybody know how this is generally resolved? Is there a way to extend the PingFederate session e.g. API call, HTTP POST to an endpoint, whatever?
Or does the SP need to construct a new authenticate request? If so, does this result in a new SAML response / token being issued with a new NotOnOrAfter date?
Unfortunately, this isn't a use case that SAML 2.0 covers and any solution that fits within the SAML 2.0 spec will probably be custom to an individual product. Additionally, is no way to have the SP extend the session at PingFed (IDP) except to do another round-trip for SSO.
Typically customers handle this by making the session at the IDP long-lived so that user's are not prompted to login again when switching between SPs.
If you control both the IDP and the SP, then I'd recommend looking at using PingAccess in conjunction with PingFederate. You can still Federate into the application via PingFed but PingAccess will allow you to manage the sessions across applications.