is OpenAM depends on the public key of the registered IDP to versify the SAML response
or depends also on the hashing algorithm in the SAML response from IDP
like Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
Note OpenAM version :13.0.0
OpenAM, acting as SAML SP, uses the public key enclosed in the KeyInfo element of the IdP meta data to verify the signature of the SAML response. It uses the signature algorithm chosen by the IdP, however it must be a supported signature algorithm.
In upcoming versions of AM, AM will (partially) implement the algsupport spec, and will take into account remote entity provider's metadata when signing SAML documents.
This means that as a hosted entity provider, AM will check the remote entity provider's preferred signing and digest methods, and will use the first algorithm that satisfies the key type and key size requirements.
This work has been completed as part of OPENAM-11266.
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.
So I'm trying to integrate single sign-on with Auth0 (being both the service provider and the identity provider) with the Atlassian stack.
Atlassian offer SAML single sign-on. However, it is telling me:
Your users won't be able to log in with SAML single sign-on until you've copied
the values for SP Entity ID and SP Assertion Consumer Service URL to your
identity provider.
I've put the assertion consumer service URL in place of the callback URL, I've done some research and I'm almost certain this is correct.
However, the issue is with the Entity ID. Where does this go?
I've not used Auth0 before, but I think you have to set it as audience in the settings, e.g. see https://auth0.com/docs/protocols/saml/saml-apps/heroku
IMHO but the configuration option is a bit misleading. Instead of using audience, using EntityID might be clearer, as this is also the term used in the SAML spec.
I am assuming that auth0 acting as a service provider.
Assertions Consumer service URL should be :
https://YOUR_DOMAIN/login/callback?connection=YOUR_CONNECTION_NAME
Entity ID of the service provider should be:
urn:auth0:YOUR_TENANT:YOUR_CONNECTION_NAME
You can download service provider metadata like below in the XML format and upload to IDP to generate configuration.
Navigate to https://YOUR_DOMAIN/samlp/metadata?connection=YOUR_CONNECTION_NAME
Additional:
URI: urn:oasis:names:tc:SAML:2.0:nameid-format:entity Indicates that
the content of the element is the identifier of an entity that
provides SAML-based services (such as a SAML authority) or is a
participant in SAML profiles (such as a service provider supporting
the browser SSO profiles). Such an identifier can be used in the
element to identify the issuer of a SAML request, response,
or assertion, or within the element to make assertions about
system entities that can issue SAML requests, responses, and
assertions. It can also be used in other elements and attributes whose
purpose is to identify a system entity in various protocol exchanges.
The syntax of such an identifier is a URI of not more than 1024
characters in length. It is RECOMMENDED that a system entity use a URL
containing its own domain name to identify itself
(SAML CORE specification, section 8.3.6)
https://www.oasis-open.org/committees/download.php/7473/sstc-saml-core-2.0-draft-15-diff.pdf
https://spaces.at.internet2.edu/display/InCFederation/Entity+IDs
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 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 am new to the concept of Single Sign On(SSO). I came to know that SAML request and response is the best way to achieve SSO process. I then started reading about SAML2.0. I came around a term NameIdPolicy in saml2.0 which was not there in saml1.0.
Definitions say that It is the format of the NameID we request from the IdP.I want to know what is that format is? I mean what data from IDP should come in the format NameIDPolicy specify? Can anyone brief me on this NameIdPolicy concept?
From the SAML 2.0 core spec, the NameIDPolicy
Specifies constraints on the name identifier to be used to represent the requested subject. If omitted,
then any type of identifier supported by the identity provider for the requested subject can be used,
constrained by any relevant deployment-specific policies, with respect to privacy, for example.
When performing identity federation, the affiliated parties must agree upon an identifier for the principal's linked accounts. The identifier string is called a NameID and its specification, including format, is the NameIDPolicy.
For example, a Service Provider (SP) initiates federation by sending an AuthnRequest to the Identity Provider (IDP) containing
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
This tells the IDP that its response Assertion XML should contain something like
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">user#example.com</saml:NameID>
where the email address represents the subject being authenticated.
You can learn more by reading SAML 2.0 Wikipedia page (well-written), the SAML 2.0 core spec and the SAML 2.0 Name Identifier document.