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.
Related
I have an endpoint, which I want to protect using Oauth2 and spring boot. The users register on the website and after the successful payment, a token with specific expiry should be issued automatically and delivered to the user. The User can revoke the token in their panel and get a new token manually.
I don't want to use password grant type as it requires sending the username and password for each request. the authorization code grant type, requires the user to enter their credentials which doesn't fit my need for automatic generation of tokens after successful payment. I'm not sure if using client credentials grant type is a good idea for my need. I could use a new client for each new user. But this seems not right to me. But correct me if I'm wrong. any idea which oauth flow I should use?
You want to authenticate end-users with OAuth2? Use authorization-code (with PKCE).
In your statements, there seem to be a confusion between authorization-server (issues tokens) and resource-server (subscriptions are resources too in my opinion). Have a look at this article for OAuth2 refresher and spring resource-server security conf.
Also, it seems to be a one-to-one relation between access-token and payed subscription. This is probably a mistake: access-token should be short lived (like a few minutes). Are your subscriptions that short?
I see two options here:
have your authorization-server add a private claim with subscription status to JWT access-token (or introspection details) and check this claim value in spring-security expressions (#PreAuthorize("..."))
configure a custom authentication converter in spring security which calls a #Repository to read subscription status in database, based on identity contained in access-token
First solution is way more efficient (persisted subscription status is retrieved from DB only when a new access-token is issued) but requires your authorization-server to be flexible enough for you to add private claim with values from a web-service or a DB. I have a tutorial to do so in Keycloak. read it AFTER the article above.
I need to develop set of microservices (rest APIs) which is to be used by web and mobile client, the microservices are sitting behind API gateway, I've to integrate with SSO (using SAML) for user's authentication, I understand that SAML token to oAuth2 token conversion has to be done so that I can verify auth token at API gateway and handle authorization there itself, but the piece which is not clear to me is that who will take care of conversion of SAML token to oAuth2 token, is it IDP who provide this functionality out of box or do I need to built up something of my own?
One possible solution which I'm thinking of is
User (from web/mobile) sign in via SSO
Gets SAML response from IDP
Send that SAML response to server to generate Auth Token
Server gets request to generate auth token, looks for SAML response and validate it against IDP
If SAML response is valid then generate auth token and send it back to client
On subsequent API request from client the token is passed as header which API gateway validates
The thing is I'm bit reluctant to implement SAML and oAuth thingy myself and looking for some ready made solution but couldn't find any, can someone please suggest of any library solving this problem, thanks in advance.
It feels like your approach is correct - it is the role of the Authorization Server (AS) to deal with SAML login integration for you. Only configuration changes should be needed, though of course you need to use an AS that supports SAML integration.
Your UIs and APIs will not need to know anything about SAML and will just use OAuth tokens. There should be zero code changes needed.
Most companies use an off the shelf AS - eg from a low cost cloud provider. My Federated Logins Blog Post summarises the process of integrating an IDP. The walkthrough uses AWS Cognito as the AS - and the IDP could be a SAML one.
I maintain a microservice that sounds like it could help you - https://github.com/enterprise-oss/osso
Osso handles SAML configuration against a handful of IDP providers, normalizes payloads, and makes user resources available to you in an oauth 2.0 authorization code grant flow.
Osso mainly acts as an authentication server though - we don't currently have a way for your API gateway to verify an access token is (still) valid, but that would be pretty trivial for us to add, we'd be happy to consider it.
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.
After configuring two UAA instances as federated, say UAA1 (Relying party)--uses--> UAA2(ID provider) through OIDC mechanism, I can use UAA1 to authenticate users defined on UAA2 through authentication code work flow. UAA1 defines shadow users in its instance, but it does not capture groups defined for users on UAA2.
For example, user1_uaa2 is on UAA2 and it belongs to a groups called uaa.test. After login through UAA1, a shadow user user1_uaa2 is created in UAA1, but its group information is lost.
How can a user's group information be propagated back to relying party in OIDC based UAA federation?
Thanks
I think according to source code, that in last version of UAA (V4.10), UAA only returns openid as scope in id_token and /userinfo, no matter if the access token has roles scope or not. That means as either OIDC or SAML identity provider, it does not provide user group information.
It seems to me its codes work and are able to retrieve group information when UAA works as SP or proxy to other IDPs. It store those information to user_info table.
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.