Skip to content

Instantly share code, notes, and snippets.

@sl4m

sl4m/saml.md

Forked from perigee/saml.md
Created December 13, 2016 09:44
Show Gist options
  • Save sl4m/095a91f430a9d300b7f8c066695341b9 to your computer and use it in GitHub Desktop.
Save sl4m/095a91f430a9d300b7f8c066695341b9 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
saml.md

Top references

SAML2 Notes

SAML2.0 is an XML based portocol using security tokens containing assertions to pass information about a principal (ex. end user) between a SAML authority (Idp-Identity provider, for planet labs, it is MS ADFS 2012 R2), and a SAML consumer (SP-service provider, for example, plotly On-Prem side authentication). The standrad was ratified as an OASIS standard in 03/2005, which eventually may be replaced by Oauth2 based OpenID.

The whole authentication procedure can be described as following chart:

SAML2

Definitions

  • Idp: asserts the identity of a user

  • SP: consumes the assertion and passes the identity information to the application

  • Idp metadata

    • EntityDescriptor
    • KeyDescriptor (Certificate)
    • Assertion

  • SP metadata

    • EntityDescriptor

INCOMMON

  • InCommon SAML-based federation
<!-- Chaining metadata provider defined in the default IdP relying-party configuration file -->
<MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider"
                  xmlns="urn:mace:shibboleth:2.0:metadata">
 
  <!--
    Refresh the InCommon production metadata aggregate every hour.
  
    Note: The defaults for minRefreshDelay, maxRefreshDelay, and refreshDelayFactor
    are "PT5M", "PT4H", and "0.75", respectively. The default for maxRefreshDelay
    has been changed below, so that the metadata is refreshed every hour ("PT1H").
    The other properties merely regurgitate their default values.
  -->
  <MetadataProvider id="ICMD" xsi:type="FileBackedHTTPMetadataProvider"
                    xmlns="urn:mace:shibboleth:2.0:metadata"
                    metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml"
                    backingFile="/opt/shibboleth-idp/metadata/InCommon-metadata.xml"
                    minRefreshDelay="PT5M"
                    maxRefreshDelay="PT1H"
                    refreshDelayFactor="0.75">
     
    <!-- Use a chaining filter to allow multiple filters to be added -->
    <MetadataFilter xsi:type="ChainingFilter">
 
        <!--
          Require a validUntil XML attribute on the EntitiesDescriptor element
          and make sure its value is no more than 14 days into the future
        -->
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P14D" />
 
        <!--
          Require the metadata to be signed and use the trust engine
          labeled id="ICTrust" to determine its trustworthiness
        -->
        <MetadataFilter xsi:type="SignatureValidation"
                        trustEngineRef="ICTrust" requireSignedMetadata="true" />
 
        <!-- Consume all SP metadata in the aggregate -->
        <MetadataFilter xsi:type="EntityRoleWhiteList">
          <RetainedRole>samlmd:SPSSODescriptor</RetainedRole>
        </MetadataFilter>
  
    </MetadataFilter>
  </MetadataProvider>
 
</MetadataProvider>
 
<!--
  This TrustEngine (beneath the Security Configuration section) is an
  implementation of the Explicit Key Trust Model (https://spaces.internet2.edu/x/t43NAQ).
  
  To bootstrap the trust fabric of the federation, each relying party 
  obtains and configures an authentic copy of the federation operator’s 
  Metadata Signing Certificate (https://spaces.internet2.edu/x/moHFAg).
  
  Fetch the InCommon metadata signing certificate and check its integrity:
  
  $ /usr/bin/curl --silent http://md.incommon.org/certs/inc-md-cert.pem \
      | /usr/bin/tee /opt/shibboleth-idp/credentials/inc-md-cert.pem \
      | /usr/bin/openssl x509 -sha1 -noout -fingerprint
  SHA1 Fingerprint=7D:B4:BB:28:D3:D5:C8:52:E0:80:B3:62:43:2A:AF:34:B2:A6:0E:DD
-->
<security:TrustEngine id="ICTrust" xsi:type="security:StaticExplicitKeySignature">
 
  <security:Credential id="MyFederation1Credentials" xsi:type="security:X509Filesystem">
    <security:Certificate>/opt/shibboleth-idp/credentials/inc-md-cert.pem</security:Certificate>
  </security:Credential>
</security:TrustEngine>

Requirements

receiving of Idp metadata (endpoints)

Ask the Idp (Identity Provider) metadata (Idp EntityDescriptor example) from On-Prem client, which contains:

  • X.509 certificate (RSA keys with a minimum size of 2048 bit)
  • endpoints
    • SingleSignOnService (SSL/TLS-protected must have)
    • SingleLogOutServer (must have)
    • ArtifactResolutionService (Reference, may have)
  • contact information

Sending SP metadata

plotly SP (Service Provider) will generate SP metadata and send back to Idp for registration. These metadata (EntityDescriptor, example) contain:

  • SP SAML2 endpoint
    • AssertionConsumerService (login endpoint, must have)
    • SSL/TLS-protected DiscoveryResponse for Idp (must have)
  • certificate (2048 bit), Service providers MUST include this encryption key in SP metadata. The encryption key is used by Idps to encrypt SAML2 assertions transmitted to the SP.

ADFS 2012 R2 particular restriction

  • AD FS 2.0 will not consume an md:EntityDescriptor element containing more than one encryption key.
  • At the deployer's convenience, a single certificate may be bound to multiple SPs in InCommon metadata. However, some implementations (e.g., AD FS 2.0) do not allow the same certificate to be used by two distinct entities.

Example

Group name in SP should identical as the one in Idp.?

 <saml:AttributeStatement>
    <saml:Attribute Name="Groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">SystemAdmin</saml:AttributeValue>
        <saml:AttributeValue xsi:type="xs:string">TeamAdmin</saml:AttributeValue>
    </saml:Attribute>
</saml:AttributeStatement>

SP will map the groups name into its groups, user attributes mapping (https://docs.jivesoftware.com/jive/6.0/community_admin/index.jsp?topic=/com.jivesoftware.help.sbs.online_6.0/admin/ConfiguringSSOwithSAML.html).

Requirements for SP

  1. Need the information about available attributes on Idp (encouraged to use InCommon Federation Attribute https://www.incommon.org/federation/attributesummary.html).
    • member
    • student
    • employee
    • faculty
    • staff
    • alum
    • affiliate
  2. Add Idp inside SP metadata
  3. SP metadata needs to be added in Idp (for trusted SP)

SAML notes

System setting:

For our client Planet Labs, the ADFS 2012 R2 is acting as Identity Provider. SAML2.0 uses Based64 encoded XML to send the information by-through. a

References

ADFS 2012 R2 with SAML2 http://blogs.technet.com/b/askpfeplat/archive/2014/11/03/adfs-deep-dive-comparing-ws-fed-saml-and-oauth-protocols.aspx

MS configure (https://technet.microsoft.com/en-CA/library/hh305235.aspx)

MS ADFS (Federated service)

SAML2

  • Redirect

Testing Environment Setting

Products

Existing API

Plan

Perquisitions

Packages

$ apt-get install xmlsec1

SAML validation tools

tutorials

Djangosaml2

Installation

Dependencies

xmlsec1

$ sudo apt-get install xmlsec1
$ sudo apt-get install libxmlsec1-dev

Installed by PIP

pip install djangosaml2

Configuration

General description of djangosaml2

Inside settings.py, add SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer', mentioned in here

Prerequisites

Key and cert files (http://onlinehelp.tableau.com/current/server/en-us/saml_requ.htm)

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment