7. Security Considerations

Recomendations

The SAML specification recommends that all communications are over HTTPS, therefore consider run DNN website only at the top of HTTPS protocol. HTTPS transport level security may be considered sufficient for the protection of any confidential data.

7.1. Overview

When signing in to a Salesforce (IdP, the authority), and once when user identity is validated, Salesforce sends back to the DNN (Service Provider) SAML response. DNN accepts “HTTP POST Binding”, where Salesforce SAML response message is in the body of a POST request. Figure below pressents example of POST body with the SAML response that DNN gets from Salesforce.

This response can be manipulated by an intruder as it passes through his browser. For example attribute username can be changed from barry@glanton.com to john@glanton.com, see figure above. In fact, I could just entirely forge the response, become “John”, and impersonate him!

Of course, SAML standard is immune to this issue, by attaching an XML Signature to each message, thus protecting that message against tampering. The SAML standard requires that all messages be signed.

In our case response is signed. Aadditionally SAML assertion in that response is signed too.

7.2. Future impovements - XML encryption

In future we will implement “XML encryption” that will be used to encrypt SAML assertion, attributes and certain identifiers. This will ensure the privacy of any confidential data contained within the XML, therefore sensitive user informations will not be visible. Will be replaced by cipher string, see image below.