Integrating one of my application with with SAML 2.0 single sign on. Using Okta provider for this. I came to the point where I receive base64 encoded "SAML response token" after successful authetication in okta and redirected back to my application. Within this token I see all the user details I need but here comes my question. Do I need to verify that response any futher or shall I just trust what I receice? Considering this token also contains signarure?
My idea for security would be to reach Okta again and verify if this was really issued by Okta. Not sure if this is even possible.
Using NodeJS for verification.
If by SAML response token you mean the samlp:Response issued according to the Web Browser Passsive SSO profile then then response contains an assertion and the assertion is signed by the Identity Provider (additionally, the whole response can also be signed).
There's a critical security requirement to always validate the response signature. This is mentioned in the SAML specs, section 4.1.4.3
The reason for this is as follows: in the Web Browser SSO Profile the token is returned by the Identity Provider in a web page that contains a simple form with SAMLResponse and RelayState fields and a bit of code that just autoPOSTs this form to your app. Technically, this means that for a short time the token is controlled by the user's web browser and this is where the token can be altered (or forged).
Thus, the protocol security heavily relies on the token's integrity which is achieved with the crypto signature - it's just a plain old XMLDSig signature applied to the SAML.
Your goal, as a token receiver is not only to validate the signature but also check the signature's certificate and compare it to the certificate you expect from the trusted provider (or a list of certificates of trusted providers).
Skipping this step makes your application vulnerable:
skipping the verification means users can alter the token (add/create/delete) claims to the assertion, the signature verification would fail but you skip it
skipping certificate matching against known certificate means users can forge their own assertions, sign it using a dummy certificate and present to your application. The signature verification step would succeed but you won't be aware that a dummy certificate was used to sign the assertion
If you don't want to do the proper token validation on a backend (don't blame you, it's a pain), then switch to OIDC. That's a better fit for authentication and authorization for the frontend.
If, however, the SAML response is sent to and handled by a backend, and some other token is being forwarded to your application, then you should evaluate what the requirement for the validation of that token is.
What isn't clear in your question is where in the user flow we're talking about, hence the number of comments on my answer.
Related
I'm building a REST API using Elixir's Phoenix framework. In the API, I need to authenticate the user by phone number i.e., via sending an SMS OTP code. After authenticating the user, the Auth server sends the Access token and Refresh token to the client. The client(mobile app) stores those tokens locally and sends the Access token in the HTTP header as Authorization: Bearer <Access_Token> in every request to resource server. My actual question is, how do resource server validates the Access token that is received from the mobile app/client?
Does resource server needs to contact Auth server to validate the Access Token? That would a lot of overhead. Please help me understand RestFull API Authentication.
Thanks for taking the time to read my question.
It sounds like you have everything working up to validating the token. You are going to need the public key for the server that signed the token. It depends on what auth server you're working with on how you get that. In some cases you may be able to preload this key as a configuration setting on your backend. Otherwise you can probably get it via https request to the auth server. Most auth servers these days I expect to provide a JWKS api that you can use to get the keys you need. Then with the token and the public key you can use your elixir jwt library to validate that the token you have was signed by the server you trust, meaning the SMS code was validated, and you can proceed with whatever is needed in the backend to handle the request.
If you're using Joken for elixir you can review https://hexdocs.pm/joken_jwks/introduction.html and https://hexdocs.pm/joken/introduction.html for more information.
how do resource server validates the Access token that is received from the mobile app/client?
The same way a nightclub bouncer verifies your driving license as proof-of-age to let you in: by validating the authority and signatures, but it does not need to phone-up your DMV to verify that your license is real because it trusts the signatures (in this case, cryptographic signatures).
That said, some systems do use "reference tokens" which are short (say 32 bytes) of meaningless random data which are used as an unpredictable record identifier for some user-permissions record held by the authorization server. The resource-server will need to contact the auth server initially, but then it can simply cache the auth result itself for some time window.
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?
So I am implementing SSO over SAML2.0 for our application. We are using saml2-js on our side and we are doing SP initiated SSO.
The implementation is ready and it is working however there are a few parts I struggle wrapping my head around.
saml2-js requires you to provide a private-key and a certificate on the ServiceProvider instance -> https://www.npmjs.com/package/saml2-js#serviceprovideroptions I don't understand what these are used for and saml2-js don't provide any meaningful description about them. I tried to find out by understanding from a SAML point of view but I still don't know.
As an IdP, Okta is the target and after setting up SAML in Okta, Okta provides it's certificate. Now I understand that part because Okta will sign the Response and on our side, the SP uses that certificate to ensure that the Assertion came from a/the trusted party. But how does Okta make sure that the request came from a trusted party? I thought the certificate saml2-js requires from us will be used for that, but as it turned out this assumption was false because Okta doesn't get our certificate in any ways
When setting up SAML in Okta (okta guide) in point 6 they require you to fill the Audience URI which by default is the SP entity_id. But this can be an arbitrary value right? What is this used for and why is this mandatory?
The service provider requires a private key if it's signing SAML messages or decrypting SAML assertions. If neither is the case, a private key shouldn't be required.
I don't believe Okta requires the SAML authn request to be signed. This isn't unusual. If the SAML authn request isn't signed, the IDP can't be sure who sent the message but this normally wouldn't present any security issues. If you click the Show Advanced Settings link in the Okta configuration you get the option of supplying your certificate. However, this is only required for signing the logout messages.
The audience URI identifies the intended recipient of the SAML response which should be the SP. It's part of the SAML protocol and as such you would expect the SP to check its value against the SP's entity ID. If you take a look at the SAML specification it talks about its purpose as helping to uphold warranty exclusions in a court of law. You can draw your own conclusions as to how useful this is.
I'm a Service Provider (SP) who wants to support multiple Identity Providers (IdP) via Web SSO profile.
I'm struggling to understand how should I negotiate SAML features (e.g. signing/not signing AuthnRequests) with Identity Provider admins.
Here's my current understanding:
I create a single sp-metadata.xml which I expose to all IdPs who want to integrate with me.
To integrate with me, IdP admins upload their idp-metadata.xml via my web interface. I validate it against my sp-metadata.xml. If their metadata features don't match with my metadata features, I show them a detailed error on upload so they can change their setup.
Questions:
Is this a valid and common approach?
How do I write SP metadata to support all or most IdPs out-of-the-box? For example, should I put "AuthnRequestsSigned = false" or "AuthnRequestsSigned = true"? It seems that Web SSO Profile does not give strict guidance on this.
About 2: You can not really validate the IdP meta data against your SP meta data. Most IdP's do not tell if they accept a digitally signed SAML AuthnRequest. They also typically do not tell which signature algorithm or keysizes they support.
Some IdP implementation do not even create SAML meta data schema compliant meta data files.
If you care about security, then you should digitally sign the SAML AuthnRequest and either ask the IdP to ignore the signature in case your SP sends it.
Also note that there some update to the spec for some time ... see the new processing rules.
Alternative: During upload ask (checkbox/radio button) if they can handle a digitally signed SAML AuthnRequest and which signature algorithm has to be used.
I.e. Microsoft ADFS and Azure AD bail out with an non-descriptive SAML error response if they can not handle the SAML AuthnRequest.
After reading a few articles on SAML, including "SAML for dummies," and the SAML wiki article, I'm still entirely unclear as to how SAML actually solves the SSO problem. Suppose I take something like a Google account as an example. My understanding is that if I go to GMail and SAML is implemented, I will be redirected to an IDP, which, let's say, is Google's sign-in authority. My browser then goes there with a redirect, and I'm asked to log in. After providing the correct login info, I return to GMail with a token and SAML response encrypted with Google Sign-in's private key, which is then authenticated using GMail's public key, thus verifying that I am, in fact, who I say I am.
What's confusing to me, is that this seems to solve the problem of signing in the first time, or into a single application, but I don't understand what happens when I now go to Google Drive. Even if my browser saves the SAML token/response as a cookie, I would have to sign in again after the token expires, which, I read, is something like 2 minutes later. Moreover, even within the same application, requests to separate resources or endpoints seem like they would time-out in the same fashion.
The only hint I have is that, according to the wiki article, step 1 has the target resource at the SP check for "a valid security context." However, if GMail and Drive are separate applications which aren't communicating with each other, how would Drive know that I already have a valid security context?
Questions:
After the initial authentication, what information needs to be sent with future requests to the same or different application/endpoint? For example, perhaps the SAML assertion saved and resent with every request.
How is this information secured/verified?
What timeouts are associated with SAML's SSO, and how are the timeouts enforced on both the SP and IDP sides?
What you are missing is that the Idp (Google's sign in page in your example) sets a session cookie on the first login. When you access Google drive as the second application, it has indeed no knowledge of the gmail session. Google drive does a redirect to the idp to get an authentication.
Now, the idp has an active session thanks to the cookie on the idp domain. That makes it possible for the idp to reply to google drive with a new assertion, generated from the persisted session information.
You're right that each assertion is normally only valid for a few minutes, but that isn't a problem as the idp can create a new assertion for each application.
For timeouts: The Idp can set a SessionNotOnOrAfter condition in the assertion to tell the SP that it must terminate the session at a given time.