Points of SAML 2.0

Does service provider have to validate a security token (provided by IdP when an user log in the web application) for each web server request?

No, the service provider does not need to validate the SAML assertion for every request.

SAML assertion contains information about the user, such as who the username is, how the user is authenticated by identity provider, and so on. Once the service provider obtains this SAML assertion from identity provider, it verifies the SAML assertion, and log-ins the user to the service provider. Once the user is logged-in, the user only needs to use the same authenticated session to access protected resource at the service provider. The user does not have to send SAML assertion.

In addition, SAML Responses are by design “one time use only” for Web SSO. This means you need to ensure your SAML solution does not allow a replay of the same message to ensure you are compliant with the spec.

Single sign on with multiple SPs. Is it possible to re-use the SAML assertion in this case?

The short answer — no, SAML 2.0 assertions are “targeted” and signed. They have a specified audience and a recipient URL. You cannot change them without breaking the signature. The assertion received by SP A contains the name of SP A as the audience and the ACS endpoint of SP A as recipient URL. Such an assertion will not be accepted by SP B.

SAML Assertion, Response & Request

The SAML Assertion included in the SAML Response to Service Provider contains pieces of data which correlate it with the original SAML Request and define recipients of the message (for example using elements SubjectConfirmationData and Audience).

SAML TOKEN validation

Token validation consists of the 3 steps:
1.Verify token is well-formed
2.Verify token is coming from the intended authority
3.Verify token is meant for the current application

More specific:

1 will include decoding the base64 encoded response, checking against schema, etc.

2 will be done via signature validation, checking the authority, seeing if it’s a response to a sent AuthnRequest and matching it, etc.

3 comes from checking the relay state and ensuring that it is a location that is “protected” by the service provider

Since the communication between SP and IDP goes through the web browser at client (SAML HTTP POST profile), is the SSL decrypted at the client browser and then ecrypted again sending to the SP or the IDP?

Yes, the SAML content is decrypted at the client browser, so yes, the client browser can read, copy or modify the SAML content before sending it to the SP. That’s why the content is always signed with the IDPs private key, so that the SP can check that it isn’t modified. If the contents are sensitive (even to the actual user), the assertion within the SAML content can be encrypted with the SPs public key.

SAML request, response, and token

For authentication in SAML, the Service Provider (the application / SP) sends a SAML AuthnRequest to the Identity Provider (the IDP).

The IDP then presents a login screen to the user.

If the user authenticates, the IDP sends an AuthnResponse to the SP.

This response contains a SAML token. This is in XML and contains the SAML assertions (the claims) about the user

When is this certificate used

The certificate is used to validate the signatures of the signed requests from the application (service provider) to the Identity Server. Therefore, the certificate is used in the below scenarios:

• Validate the signature of the SAML2 authentication requests and the SAML2 logout requests that are sent by the service provider
• Encrypt id_token sent to the service provider in OIDC Authentication Response
• Validate Signed Request Object sent in OAuth2/OIDC Authorization Request

PEM format

PEM is a Base64 encoded format, therefore contains ASCII character and easier to deal with rather than a binary encoded certificate.

How to obtain the PEM encoded certificate

Direct conversion from jks to pem file using the keytool

keytool -exportcert -alias selfsigned -keypass password -keystore test-user.jks -rfc -file test-user.pem

SAML digest algorithm

SAMLSSODigestAlgo is used to specify the SAML digest algorithm. The SAML digest algorithm is part of the validation process to ensure message integrity.

XML Signature’s ‘Signature Method’ algorithm vs. ‘Digest Method’ algorithm

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
      <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
      <ds:Reference URI="#_884D49DAD03AD60748547F8322C11AA0">
        <ds:Transforms>
          <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
          <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        </ds:Transforms>
        <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <ds:DigestValue>...</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>...</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:KeyName>...</ds:KeyName>
    </ds:KeyInfo>
 </ds:Signature>

Signature Method Algorithm :(http://www.w3.org/2000/09/xmldsig#rsa-sha1)

Digest Method Algorithm :(http://www.w3.org/2000/09/xmldsig#sha1).

Signature Method Algorithm ‘rsa-sha1’ means that the content to be signed must first be washed (digested) using SHA1 and then signed using RSA.

Digest methods Algorithm elements refer to their parent reference element. You can have different digest methods for your multiple reference elements, and a different signature algorithm to hash and sign all references.

NOTE:
Some information obtained from stackoverflow.com