Pages

Friday, February 13, 2015

Office 365 Integrating with Shibboleth 3.0

Enabling the Browser based Single Sign-On or Service Provider (SP) initiated Single Sign-On  between  Office 365 to Shibboleth Identity Provider (IDP 3.0) as follows:

Pre-Requisite:

1. Installed and Configured the IDP Server 3.0
2. Office 365 Domain Should be created and verified.


Shibboleth IDP 3.0 Configuration:


1. Setting the Trust IDP to SP

    1.1 Import the Office 365 metadata

    
    Go to the ID_HOME/metadata directory and execute the following command to download the office 365 metadata:

   wget https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml

    1.2 Register the metadata with IDP

   
    Go to the ID_HOME/conf directory and add the following content in metadata-providers.xml file:
   
<MetadataProvider id="microsoftonline"  xsi:type="FilesystemMetadataProvider" metadataFile="%{idp.home}/metadata/federationmetadata.xml"/>

 

2. Setting up the Encryption optional for SP's

    Go to the IDP_HOME/conf directory and modify the idp.properties file. 

   2.3 Modifying the idp.properties

      This configuration is required to setup optional encryption parameter for SP's metadata encryption keys. If the metadata contains encryption keys and it will apply while encrypting the data else it is optional.

 idp.encryption.optional = true



3. Releasing the Attributes from IDP to SP

   As per the Microsoft the following attributes are required for office 365 SSO:

   1. ImmutableID
   2. UserId

    Go to the IDP_HOME/conf directory and modify the attribute-resolver.xml and attribute-filter.xml file to release the attributes from IDP to SP.

   3.1 Defining Attributes in attribute-resolver.xml File 

   The following content needs to be added in the attribute-resolver.xml file:

    ImmutableID Attribute Definition
   
The immutableID is unqiue and shouldn't change any time. In my case common name (cn) is unique.

    <resolver:AttributeDefinition id="ImmutableID"  xsi:type="ad:Simple" sourceAttributeID="cn">
            <resolver:Dependency ref="myLDAP" />
            <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
   </resolver:AttributeDefinition>

     The SAML2StringNameID is deprecated in shibboleth 3.0. If you want to compatible with Shibboleth IDP 3.0, you need to follow the step 5 to generate the Name ID Policy and also modify the attribute definition configuration as follows:

      <resolver:AttributeDefinition id="ImmutableID"  xsi:type="ad:Simple" sourceAttributeID="cn">
               <resolver:Dependency ref="myLDAP" />
               <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="urn:mace:dir:attribute-def:ImmutableID" friendlyName="ImmutableID"  encodeType="false" />
   </resolver:AttributeDefinition>

    
 UserId Attribute Definition

<resolver:AttributeDefinition id="UserId" xsi:type="ad:Simple" sourceAttributeID="mail">
            <resolver:Dependency ref="myLDAP" />
            <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="IDPEmail" friendlyName="UserId" />
   </resolver:AttributeDefinition>

 

 3.2 Releasing Attributes from IDP to SP in attribute-filter.xml File:


 The following content needs to be added in the attribute-filter.xml file:

   <afp:AttributeFilterPolicy id="PolicyForWindowsAzureAD">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="urn:federation:MicrosoftOnline" />


       <!-- Release mail as Windows Azure AD User ID -->

       <afp:AttributeRule attributeID="UserId">
                <afp:PermitValueRule xsi:type="basic:ANY" />
       </afp:AttributeRule>


       <!-- Release Immutable ID to Windows Azure AD -->

       <afp:AttributeRule attributeID="ImmutableID" >
            <afp:PermitValueRule xsi:type="basic:ANY" />
       </afp:AttributeRule>

       <!-- Denying the transient ID release to Windows Azure AD -->

       <afp:AttributeRule attributeID="transientId">
            <afp:DenyValueRule xsi:type="basic:ANY"/>
       </afp:AttributeRule>

   </afp:AttributeFilterPolicy>


4. Generating the Name ID Configuration

   Go to the IDP_HOME/conf directory and modify the saml-nameid.properties and saml-nameid.xml file to generate the Persistence Name Id and this Id going to release to Service Providers as Name ID Policy and This Id going to be used to retrieve the attributes using AttributeService.
 

   4.1 Configuring the SAML Name ID

     The Name ID generation needs to be configured to release persistent ID as follows:

      Persistent ID Generator configuration in saml-nameid.properties

     
      The following properties needs to uncommented to configure the Persistence Name Id   Generator:

      idp.persistentId.generator = shibboleth.ComputedPersistentIdGenerator
      idp.persistentId.sourceAttribute = cn
      idp.persistentId.salt = changethistosomethingrandom

    In the above configuration I have chosen cn is my source attribute. If you want to modify the source attribute according to your environment. IDP going to release the name id policy as a cn persistence attribute.


   

Persistent ID Generator configuration in saml-nameid.xml

The following content needs to be added in the saml-nameid.xml file and also you need to modify the  attribute source ids. In my case my persistence source id is ImmutableID.

<ref bean="shibboleth.SAML2PersistentGenerator" />
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
            p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
            p:attributeSourceIds="#{ {'ImmutableID'} }" />

5. Generating Name ID Consumption Configuration

Go to the IDP_HOME/conf/c14n directory and modify the attribute-sourced-subject-c14n-config.xml and subject-c14n.xml to compatible with Attribute Encoders as per Shibboleth 3.0 Specification.

5.1 Configuring the Name ID Attribute in attribute-sourced-subject-c14n-config.xml 

 This configuration is required to add the name identifier in the attribute-sourced-subject-c14n-config.xml because IDP going to release NameIDPolicy in the SAML Assertion.  I am using the common name (cn) as the subject name identifier and I have configured the cn as follows:


    <util:list id="shibboleth.c14n.attribute.AttributesToResolve">
        <value>cn</value>
    </util:list>

    <util:list id="shibboleth.c14n.attribute.AttributeSourceIds">
        <value>cn</value>
    </util:list>

If you want to add more than one field as a subject name identifier as follows:


    <util:list id="shibboleth.c14n.attribute.AttributesToResolve">
        <value>cn</value>
        <value>mail</value>
    </util:list>

    <util:list id="shibboleth.c14n.attribute.AttributeSourceIds">
        <value>cn</value>
        <value>mail</value>
    </util:list>


Note: These attributes are configured in the attribute-resolver.xml file.


5.2 Configuring the subject-c14n.xml File


     Configuring the SAML2 Persistence Name ID

      Un-Comment the following lines to configure the SAML Name Id:

      <bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow" />
      <ref bean="c14n/SAML2Persistent" />
    

       Configuring the SAML2 Name ID Format


       Add the <value>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</value> in the <util:list id="shibboleth.NameTransformFormats"> bean.


6. Restart the Tomcat Web Server


Office 365 Configuration:


1. Setting the Trust From SP to IDP

   
   Open the Windows Azure Active Directory Power Shell Window.
   Execute the following command to authenticate the user and also establish the connectivity from client machine to windows azure AD Server.

     Connect-MsolService

     After executing the above command, you need to provide the user name and password to authenticate the user against the windows azure ad.

    Configuring the SSO

 The following scripts needs to be executed to configure the Single Sign-On. I have used the idp-signing.crt certificate in the script because this certificate is self signed and this certificate is available in the IDP_HOME/credentials directory.


 $dom = "<Replace Your Federated Domain>"
 $idpHost="<Replace Your IDP Host>"

$fedBrandName="IDMGT Shibboleth"

$url = "$idpHost/idp/profile/SAML2/POST/SSO"
$ecpUrl = "$idpHost/idp/profile/SAML2/SOAP/ECP"
$uri = "$idpHost/idp/shibboleth"
$logoutUrl = "$idpHost/profile/SAML2/POST/SLO"


$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("idp-signing.crt")

$certData = [system.convert]::tobase64string($cert.rawdata)


Set-MsolDomainAuthentication –DomainName $dom –federationBrandName $FedBrandName -Authentication Federated  -PassiveLogOnUri $url -SigningCertificate $certData -IssuerUri $uri -ActiveLogOnUri $ecpUrl -LogOffUri $logoutUrl -PreferredAuthenticationProtocol SAMLP

Get-MsolDomainFederationSettings -DomainName $dom



Testing the SSO Will Come soon

5 comments:

  1. hey great post..but i need help with how to test this sso integration?

    ReplyDelete
  2. $logoutUrl = "$idpHost/idp/profile/SAML2/POST/SLO"

    ReplyDelete
  3. if you already have presistent id generation for something else, this isn't good. You can make condition in the saml-name.xml to generate only for that SP.

    ReplyDelete
  4. trying to set this up with IDP, do you really need an SP with office 365? can we not use Azure AD nowadays or is this how you are doing it?

    otherwise great article! ;)

    ReplyDelete