CODEWITHSUNDEEP
sslsaml
AXC
AXC

Reputation: 1

SAML over SSL - SAML token

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?

If yes, SAML token easily stolen at this point? What can we do to prevent it?

How can I prevent token replay? (on top of setting the before and after SAML configuration)

Are SAML token only use once by the SP? Can we expire a token right after the IDP send it?

Upvotes: 0

Views: 855

Answers (3)

Andreas Åkre Solberg
Andreas Åkre Solberg

Reputation: 1735

There is no such thing as a SAML Token, there is instead an SAML Assertion inside the response. And yes, when it is sent front-channel, the user may inspect the message.

To avoid the user from being able to inspect the assertion, which usually includes information about who the user is (and some attributes) rather than a token that gives the user permission to do anything (as you are used to with OAuth etc), the assertion could be encrypted at message level. It is up to the IdP to decide wether or not to encrypt the assertion, but it requires sufficient info about the SPs certificate in order to do so. It also have to be supported by the SP to decrypt messages for it to make sense.

Upvotes: 1

wabba7ack
wabba7ack

Reputation: 1

Many SAML assertions are not yet encrypted by default (ie...WebEx SAML). Be sure to check for this setting with your IdP and verify that the SP can accept an encrypted SAML assertion...not all can.

You can check to see if your message is being encrypted by using Fiddler to review the assertion itself. Can you see information being passed? If so, you may want to review your app settings.

If you google Fiddler or SSO tracer for Firefox, you can see steps to grab the assertion and check for yourself. If the request in text mode can see things like the Subject info (NameID for example), then it is not encrypted.

I.e.,

<Subject>
    <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">JohnDoe</NameID>
    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData NotOnOrAfter="2016-05-01T16:51:59.525Z" Recipient="https://null.webex.com/dispatcher/SAML2AuthService?siteurl=null" />
    </SubjectConfirmation>
</Subject>

Upvotes: 0

Anders Abel
Anders Abel

Reputation: 69250

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.

The SAML SP should guard against replayed tokens.

A normal lifetime of tokens issued by an Idp (as set by a valid NotOnOrAfter attribute) is 2 minutes for authentication tokens.

Upvotes: 4

Related Questions