Is having signed metadata useful in any way outside of the initial metadata exchange? What are the risks in skipping the signature the signature check?
This is only to secure the initial exchange. About the risks. Its recommended to secure the transport of thw meta data in some way to ensure trust. This is just one more alternative to ensure trust. If you trust the channel where the metadata is delivered, there is no need to sign
Related
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.
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.
Is there a point for implementing Assertion Level Encryption (and Attribute Level Encryption) if we are already communicating via SSL (https)?
If you're using the browser profile, whereby the SP and IdP exchange messages via the user's browser, SSL alone does not protect against a man-in-the-middle in all cases. Take for example the scenario where a user is on unsecured Wi-Fi and a malicious user intercepts traffic, swapping a self-signed SSL cert for the CA-issued one. If a user clicks through the warning, their transport-level security is negated and confidentiality may be breached. If on the other hand the sensitive parts of the assertion are protected via message level encryption, the man-in-the-middle in the above scenario still cannot read the message despite the user's poor judgement, and confidentiality is ensured.
It depends. How sensitive is the data within your Assertion? Typically you'll see message or attribute-level encryption when the actual user data is considered sensitive or confidential. If your SAMLResponse is not encrypted, in theory someone (browser plugins) could inspect its contents. So, while it is digitally signed to prevent tampering, the data could be leaked.
I've seen a bunch of flow chart on how it is passed around between Identity Provider (IdP), Service Provider (SP), and Browser via Redirects. However it seems unnecessary to me right now, so i know i'm missing something.
Can someone provide me a use case where a SAML Artifact is required (or very useful) compared to not using one?
Thank you.
Typically, the intent of the artifact binding is to reduce the flow of SAML messages through the browser itself. This could be due to browser restrictions (browsers that have limits on query string / POST payload size) or no support for JavaScript (for auto-submitted forms), or even to improve the security model of how the SAML messages are transported. By using artifacts, sensitive data carried through the SAML Assertion / Attribute Statement is not passed through the browser, so it can be hidden from the end user or attackers between your site and the end user. This confidential data would only be directly resolved between sites through a back channel lookup.
Section 3.6.2 of the SAML 2.0 Bindings specs summarizes it best:
The HTTP Artifact binding is intended for cases in which the SAML
requester and responder need to communicate using an HTTP user agent
as an intermediary, but the intermediary's limitations preclude or
discourage the transmission of an entire message (or message exchange)
through it. This may be for technical reasons or because of a
reluctance to expose the message content to the intermediary (and if
the use of encryption is not practical). Note that because of the need
to subsequently resolve the artifact using another synchronous
binding, such as SOAP, a direct communication path must exist between
the SAML message sender and recipient in the reverse direction of the
artifact's transmission (the receiver of the message and artifact must
be able to send a request back to the artifact
issuer). The artifact issuer must also maintain state while the
artifact is pending, which has implications for load-balanced
environments.
Expanding on Scott T's answer, the SAML Artifact Profile was designed to improve security. To prevent a user from modifying it's SAML Assertion mid-traffic (such as changing Username, roles, etc), SAML 2.0 suggests that developers sign assertions via XML signatures. XML Signatures though are extremely vulnerable to XML wrapping attacks because of issues in every languages existing XML parsers. Visit https://www.usenix.org/conference/usenixsecurity12/breaking-saml-be-whoever-you-want-be to see XML wrapping attacks in action against SAML Assertions.
The SAML Artifact Profile solves this issue by creating a one-time use "artifact" that is passed to the Service Provider by the user (via redirect or post) rather then the SAML Assertion. When the Service Provider receives the one-time use artifact, it sends a SAML Artifact Resolve Request (containing the artifact) to the Identity Provider's Artifact Resolution Service (ARS). The ARS then responses with a SAML Artifact Response (containing the user's SAML Assertion) thereby preventing the SAML Assertion from ever being modified by the user as it is directly received by the Service Provider over a back channel.
A SAML message is transmitted from one entity to another either by value or by reference. A reference to a SAML message is called an artifact. The receiver of an artifact resolves the reference by sending a request directly to the issuer of the artifact, who then responds with the actual message referenced by the artifact.
Refer SAML 2.0,
Without the artifact there is no way to get to the actual message.
Note that this is only required when using HTTP Artifact Binding. (As opposed to the more common HTTP POST Binding which simple sends the SAML message).
Another reason for using HTTP Artifact binding is that you can use SSL to ensure SAML message integrity and confidentiality. The SAML requester and responder do not need to sign, validate, encrypt, and decrypt the SAML message.
it may be considered out of interest nowadays but the artifact profile is also useful if you have a low bandwidth between the user agent and sp & idp servers and a better bandwith between sp & idp. The (heavy) assertion does not circulate from the idp to the ua and from the ua to the sp and it may show better performance in certain circonstances.
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