torijacarlos

← dev

Identity Management

Vocabulary

• Identity Provider (IdP): Centralized service that handles the information of your users Can verify a user is who they say they are. Can use multiple methods.

Provisioning

How we keep in sync the user profiles information between Idp and SP

• IdP should* be the Source of Truth

We can do it:

• Just in time: When the IdP sents a response, and the user does not exists in the SP, it should be created If it exists, but data differ, SP should update information
• Real time: As things change in the IdP, it should update information in the SPs

• SPs may choose to not be in sync with IdP for several reasons, like compliance or regulations

---

SAML (Security Assertion Markup Language)

Vocabulary

Let's say I want to login to A Cloud Guru.

• User Agent: My Web browser. An Application.
• Service Provider: Application to authenticate. A Cloud Guru is the Service Provider
• Identity Provider: Who will provide the identity authn/authz. ACG has a ton of integrations like Google, Twitter and Github

Implementation

SAML Request

This will be stringified, encoded and passed in the query string to the IdP once the SP redirects there

• ID: Generated by the SP
• IssueInstant: Usually used to give the request a lifetime
• Destination: Points to the IdP
• AssertionConsumerServiceURL: Where the Response needs to go to once the user is authn

<samlp:AuthnRequest ID="" IssueInstant="" Destination="" AssertionConsumerServiceURL="">
    <saml:Issuer> </saml:Issuer>
</samlp:AuthnRequest>

This xml is heavily minimized, there's a ton of information missing

SAML Response

This is sent to the SP AssertionConsumerServiceURL once the user has authenticated

• ID: Generated by the SP
• InResponseTo: ID contained in the SAML Request
• Destination: The AssertionConsumerServiceURL
• Assertion:
  • Subject: User information
  • Conditions - (NotBefore/NotOnOrAfter): Validity window for the saml response
  • AttributeStatement - Attribute: Additional metadata

<saml2p:Response ID="" InResponseTo="" Destination="">
    <saml:Issuer> </saml:Issuer>
    <saml2:Assertion>
        <ds:Signature> </ds:Signature>
        <saml2:Subject> 
            <saml2:NameID> </saml2:NameID>
        </saml2:Subject>
        <saml2:Conditions NotBefore="" NotOnOrAfter=""> </saml2:Conditions>
        <saml2:AttributeStatement> 
            <saml2:Attribute> </saml2:Attribute>
        </saml2:AttributeStatement>
    </saml2:Assertion>
</saml2p:Response>

This xml is heavily minimized, there's a ton of information missing

For both Request and response:

• Issuer: The SAML authority that is making the claim(s) in the assertion. The issuer SHOULD be unambiguous to the intended relying parties

Weak points & Best practices

It boils down to bad implementation, there is nothing inherently insecure with the protocol

• Flawed Assertion Validation: The SP incorrectly validates the information in the SAML Response
• XML Parsers: Point of exploit for remote execution.
  • Disable DTD Fetching to defend against XXE
  • Use canonicalized XML: Normalize XML to protect against inner comment node manipulation
  • Validate the schema: Defend against XML Signature Wrapping (XSW) Attacks
• Insecure Libraries
• Limit accepted signature algorithms
• Use HTTPs
  • Still vulnerable to XSS and Replay
• Validate the parties (Destination, audience, recipient, issuer)
  • Prevent IdP impersonation
• Enforce the validation windown
• Limit the buffer size accepted for the SAML Response

Sources

SAML

• SSO: SAML vs OAUTH vs OIDC
• SAML Overview
• A Developer's Guide to SAML
• SAML Specification haven't read complete 👀