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.
Related
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.
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.
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
I have set up a single sign on(SSO) for my services. All the services confirm the identity of the user using the IDPorvider(IDP). In my case I am also the IDP.
In my saml request, I have included the following:
1. the level for which auth. is required.
2. the consumer url
3. the destination service url.
4. Issuer
Then, encrypting this message with the SP's(service provider) private key and then with the IDP's Public key. Then I am sending this request.
The IDP on receiving the request, first decrypts with his own private key and then with SP's public key. In the saml response:
1. destination url
2. Issuer
3. Status of the response
Is this good enough? Please give your suggestions?
In general it goes something like this. There is encryption and then there is singing in SAML. You never want to be in production without digital signature sbeing used for SAML. You can disable signature processing for testing purposes I suppose. We alow this in SiteMinder Federation Servcies (SMFSS) for testing purposes only. So, with that being said you're not saying anything about digital signatures and are only talking about encryption.
But here is a rundown of the two in my own very dumbed down description which although I sound silly with the way I explain it I am hoping it will help you. And if you already know this I apologize in advance. One more thing is that this is very basic but you can get more details on google searching for encrytpion, decryption, certificates, etc.
Actually, here is a rundown of what I use to train new support folks for Federation with SMFSS (SiteMinder Federation Services) and at the end is the section I wrote on certs. This was just something I wrote up very quickly and is not very slick looking but it defintiely gets the job done, and quickly. It was written as sort of a copy of what I do with POC SAML 2.0 POST customers who already have SiteMinder setup. I just figured I would give you this since it has a lot of tools you may find useful once you get going in case you were not aware of them already. ;-)
You will need two environments with Agent, Agent OP, Policy Server, Policy Server OP. Need two agents so one can be IDP and one SP.
To set up Agent Option Pack see:
Chapter 8: Federation Web Services Application Setup & Deploy Federation Web Services as a Web Application & Configure ServletExec to Work with Federation Web Services
Now set up the SAML 2.0 POST authentication: You should use the following as it is step by step. But first see the chapter on settings that must match as they need to match for the IDP and SP sides. The chapters below for IDP and SP set up are pretty much step by step, really, Follow 14 and 16 step by step and you’re good to go.
Chapter 22: Configuration Settings that Must Use the Same Values
Then use this to set up the IDP and SP:
Chapter 14: Configure SiteMinder as a SAML 2.0 Identity Provider
Chapter 16: Configure SiteMinder as a SAML 2.0 Service Provider
Run your SAML 2.0 transaction and get a Fiddler Trace of it. Pull out the certs and create a .cer file. Pull out the assertion and check the XML online using the tools below.
Set up Fiddler Tool and make sure you have HTTPS Decryption enabled. I had the link here but just go to gllgle and type in "Fiddler Tool HTTPS decryption" and you'll get it.
Used to review the URL posted or redirected with SAML transactions taken out of Fiddler Usually:
https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php
I have used this one multiple times to validate XML (the assertion) when I get parsing errors or other errors with partners saying our assertion is not good or if we have a partners assertion that is not good. I like to check the syntax first and if that is fine then check SAML specs to see if they have correct values in the SAML assertion itself. In other words make sure it is SAML compliant.
http://www.w3schools.com/dom/dom_validate.asp
HINT: You can take the base 64 encoded cert info out of our logs or the Fiddler Traces and paste to a notepad and save it as name.cer. Then when you open this file you can look at the cert the customer is using. This is helpful because then you can see if they have the right cert and see who their Root CA is or their intermediate Root CA. Make sure you get all the data including the = or == that may be at the end of the lines for the cert info.
When performing SLO or Artifact the partner will need to connect on the back channel to a web server on the other partners site. When this happens the Web Server being connected to is being served over SSL/HTTPS. This means that the one connecting to that server must have the ROOT CA cert which signed the web sever’s cert in it’s keystore. The theory of this is the same as when you open a browser and connect to an HTTPS web server. All browsers come with the major Root CA certs already imported into them. The whole point of this is that when you put a cert on a web server it is not really for protection it is to let anyone who connects know that you really are that website and really are who you say you are. The fact that you have a cert makes your site be HTTPS and the reason you believe they are who they say they are is that they give you their cert when you connect and if you have the ROOT CA for that cert on the website then this means you trust their ROOT CA. if you trust their ROOT CA then you can connect. If you do not have the ROOT CA cert imported into your browser then you can not connect over SSL/HTTPS to that webserver.
**Encryption and Decryption (if a packet is reads off the wire then the data is encrypted for safety of packet data):
Encryption is done on the IDP side and you can encrypt the entire assertion, NameID value, Attributes and perhaps more?
Encryption is done on the IDP side using the PUBLIC Key Certificate (SP’s cert) which is given to the IDP offline by the SP.
When the SP gets the assertion (or whatever the IDP encrypted) then it must have it’s private key in it’s keystore so that it can decrypt the data and read it. This is the decryption.
The reason this is secure and protects the data is that ONLY the SP should have their own PRIVATE key. Thus if this packet was stolen no one can decrypt it but them.
***Signing and verification – This is not SECURE as it does not encrypt the data. It is not meant to be secure for the packets it is meant to tell someone you really are who you say you are. So if you sign and assertion your partner will know it came from the IDP they expected it to come from.
The IDP must use their public/private key PAIR to sign the data.
The SP must use the IDP’s PUBLIC key (given to the SP offline) to verify the signature. The reason you know the data is from that IDP is that ONLY data signed with the IDP’s private key and be decrypted with their public key. In other words, you can’t pretend you are that IDP and send signed data to the SP and get them to think it is the IDP because the public key for the IDP can only be used to verify things signed with the matching private key. This proves you are who you say you are.
end silly technote I wrote**
I hope you find the certs info and tools useful in your future SAML endeavours! Happy Federating!
update - I was not able to post all the links but some were just base 64 decryption as it will allow me to post only two I am posting the most needed two.
Thanks!
Crissy Stone
CA Technologies SiteMinder Support