Some time ago I've worked on setting up SSO user authentication in a web application. The specific IdP was an ADFS server, but I don't think that's very important.
When configuring the application's SSO settings, I noticed that the IdP certificate's fingerprint is required, but not the certificate itself. Now, as I understand, the fingerprint is used by the application to validate the IdP's signature on the issued SAML token.
The question is how can the application verify the signature with just the certificate fingerprint? Doesn't it need the certificate's public key, which is part of the certificate itself, but not of it's fingerprint? How does this signature verification process work?
The fingerprint is exchanged out-of-band between the sender and the receiver and is configured on the receiving end. It uniquely identifies a certificate with the public key that the sender uses to sign the SAML messages that it sends.
The certificate itself can then be sent in-band as part of the SAML message itself. The receiver will compare the fingerprint of that certificate against the stored fingerprint to confirm that is dealing with the appropriate sender and associated key before cryptographically verifying the SAML message with that key.
This has the advantage that only a small message needs to be exchanged out-of-band beforehand. This may be useful e.g. when read out over a telephone line but has the downside that the complete certificate needs to be sent with each message (well, in principle at least the first message...) which increases the size of each message.
Related
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.
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 have a question regarding saml workflow when certificates are being requested from the SP.
We are a SP and have implemented sso using saml for a number of customers. We send a standard request (doesn't include any certificate, or request isnt signed) to the clients IDP and handle their response validating their x509 cert which was shared pre-release and have installed on our server.
This is the only work we do with certificates at the moment. We now have a client who is asking for our x509 cert. We currently dont have a certificate, and i'm wondering what changes in our current workflow based on this request.
Do we need to sign our initial response or add the certificate into the body of the response? I'm a little in the dark to whats required from our end and what changes were going have to make.
It clearly is adding some other layer of security but could someone explain the workflow when this extra signing is used ?
Thanks in advance.
They probably want to encrypt the SAML Response containing attribute statements, etc. They would use your public key (i.e. the SP's certificate) to encrypt the payload, and then you (as the holder of the SP's private key) would be the only one that could decrypt that content.
This is a perfectly reasonable request from the IdP.
And realistically, you should be signing your AuthnRequests and LogoutRequests with a certificate. You don't need to provide the encryption cert in the AuthnRequest, the IdP will use the cert in the metadata to encrypt the content.
Quick question,
Could there be any explanation for the fact that the IdP sends a certificate that is old and doesn't match the certificate that the SP expects, but SSO still works?
Could it be that the public keys somewhere else still match?
I have seen certificates where the public key doesn't change but the expiry date, serial number etc do change. This isn't common though.
The more likely scenarios are:
(i) the IdP is using the certificate expected by the SP,
(ii) the SP is using the embedded certificate,
(iii) the SP isn't verifying the signature.
If you take a look at the received SAML response it normally includes the base-64 encoded certificate embedded in the XML signature.
You can check this against the certificate you are expecting.
I am trying to understand the SAML 2 protocol and in that process got a little bit lost with the signature and certificate business.
Basically, I am not clear of when each of the certs are used.
Service Provider Meta Data and Identity Provider Metadata - do we need to generate certificates/keys as a part of the SP and IDP metadata? If so how/when will these certs be used?
HOK token also needs a certificate - when does that come into picture? Does the principal's certificate/public key needs to be exported to the IDP also along withe SP's certificate?
When using bearer tokens (they do not have any certs associated with the principal) is the SAML response/assertion still signed? Is it different from the ds:keyInfo in the SAML response in this case?
Thanks a bunch for the help!!
1.
Certificates in SP and IDP metadata are typically used for two purposes digital signing and digital encryption. Attribute "usage" on metadata makes the discrimination. Certificates are typically included in the metadata, but they could also be ommited and provided out-of-band (e.g. by direct configuration in IDP and SP, if supported). These keys identify the SP and IDP machines, they have nothing to do with the users.
When SP sends a SAML message towards IDP the message can be digitally signed using SP's private key (whose public key + certificate is included in the SP metadata and available to IDP), IDP is able to verify the SP's signature using the SP's public key.
When SP wants to encrypt part of the SAML data (whole message, assertion, name ID, attribute, ...) it uses public key declared in the IDP's metadata, IDP then decrypts the data using its private key.
Sometimes metadata can contain multiple signing or encryption keys, e.g. in case of certificate rollover before expiration.
2.
Bearer mechanisms are used to make sure that the entity (e.g. web browser) who is presenting a SAML message is allowed to do so. In SAML WebSSO AuthnResponse message gets issued by the IDP, but is delivered to the SP by the browser. HoK SubjectConfiguration tells that we are identifying the presenter by making sure that it can prove posession of a private key whose public key/certificate is included in the SubjectConfirmation element. This is typically done by usage of SSL/TLS Client Authentication (i.e. user installs private key in browser and uses it to authenticate toward SAML service when opening the HTTPS scheme with SSL/TLS).
So here we are dealing with keys issued directly to users, not to SP/IDP services. Whether or not you need to import user's certificate(s) to the IDP or not is IDP-implementation specific.
3.
Yes, the messages will still be signed (when configured to be) and KeyInfo in the SAML response will be the same in both cases.
Cheers,
Vladimir Schafer