Single sign on helps with creating an enterprise-wide authentication framework.

mydigitalstructure supports Security Assertion Markup Language (SAML) 2.0.

JWT is also supported

mydigitalstructure is the "service provider (SP)".
Using the identity provider initiated scheme; a mydigitalstructure receives a signed (using private key) SAML assertion via a http POST request.  This is then checked using the pre-loaded identity provider (IdP) public key. If OK, the mydigitalstructure authentication is completed in the context of the logon name (user) supplied with the assertion.
The logon name (username) and password are sent to mydigitalstructure LOGON endpoint, and then rather than using the mydigitalstructure LOGON authentication engine, it uses a pre-configured external webservice endpoint and trusts the "true"/"false" response from it.
SAML 2.0

SAML 2.0 is a standard for exchanging authentication and authorization data between security domains.

mydigitalstructure, by default, expects the logon name of the user to be an email address, as returned by the Identity Provider.



1 Setup Store the IdP Name, Entity ID, URL and X509 Certificate against the site using SETUP_SITE_MANAGE.
2 User navigates to site URL

The IdP URL is returned with method CORE_GET_USER_DETAILS, if the user is not authenticated (eg status=ER) then the view-controller code reacts to it.

e.g. removes the password box and changes the Logon button to say Logon with [[IdP service name]] or creates an "OR" option.

3 Authentication with IdP

The user clicks "Logon with [IdP Name]" which redirects to the IdP.

4 Authentication with SP (mydigitalstructure)

After the user authenticates with the IdP, the IdP https posts back to [[site url]]/rpc/logon/?method=LOGON_TRUSTED with data samlresponse=[xml base64 encoded]

 4a Getting the SAML response & decoding.

The LOGON_TRUSTED method then;

  • gets the samlresponse data
  • converts it from base64 to XML
  • then checks that the samlresponse is valid, in that it hasn't been altered in-transit and that it is from the IdP i.e. the signature was created using the private-key that matches the public-key issued and stored against the site.
4b How mydigitalstructure LOGON_TRUSTED method checks that samlresponse is valid and then does LOGON.

After data has been decoded and then converted from base64 to XML (text).

Using the example below;

  • Gets the URI [1] for the start of the XML that the IdP (in this case Google) used to create the SignatureValue [5].

  • In the example below that is all the assertion XML [3]

  • Then using the X509Certificate (public-key) [4] decrypt the SignatureValue [5]
    -- and then compare to the XML [3]
    -- if they match then proceed else return "ER"

  • Knowing the XML has not been tampered in transit and was signed with issuers private-key, then get the Issuer value [9] and check against the IdP Entity ID stored against the mydigitalstructure site (done previously using SETUP_SITE_MANAGE)
    -- if matches then check that [7] matches the current site URL
    -- if matches then OK to proceed with LOGON

  • Then the "valid from/to dates" are checked [8]

  • The that the "InResponseTo" value equals "mydigitalstructure_[logonkey]"

  • mydigitalstructure then calls LOGON with logon=NameID in XML [6]

  • And on successful logon, mydigitalstructure returns to the browser with a 302 redirect to the "Audience" contained in the response XML [7] using the https protocol.  If logon is unsuccessful it does the same redirect but with "/#logonStatus=Error".
Example samlresponse (decoded)


Data protection using cryptography
SAML 2.0
SAML Overview
Public-key cryptography
Digital signatures
OneLoginBest PracticeSDKTester
Intro video
Using Google as a SAML Identity Provider
Why 509 Cert in response?
Self-sign Certificate