Skip to main content
Jamf Nation, hosted by Jamf, is the largest Apple IT management community in the world. Dialog with your fellow IT professionals, gain insight about Apple device deployments, share best practices and bounce ideas off each other. Join the conversation.

Configuring Single Sign-On with Shibboleth

Overview

This article explains how to configure Single Sign-On (SSO) in Jamf Pro with Shibboleth Identity Provider as your SAML 2.0 Identity Provider (IdP). When SSO is enabled, by default users logging into Jamf Pro are redirected to the Shibboleth login page. After successful authentication, they are directed back to the Jamf Pro Dashboard.

The SSO configuration procedure provided in this article was tested with Shibboleth Identity Provider 3.2.1 and with LDAP connected to the Shibboleth instance.

Versions Affected

Jamf Pro 9.97 or later

Requirements

  • Jamf Pro user accounts or groups that have matching users or groups in Shibboleth Identity Provider
  • User with administrative access to Shibboleth Identity Provider
  • User with Single Sign-On (SSO) privileges in Jamf Pro

Procedure

Single Sign-On with Shibboleth Identity Provider requires configuring your Shibboleth server and Jamf Pro simultaneously. It is important to note that each configuration is unique to your environment, and additional steps may be necessary.

The procedure involves the following steps:

  1. Get Metadata XML file from Shibboleth Identity Provider
  2. Configure Single Sign-On in Jamf Pro
  3. Add a new Relying Party to Shibboleth Identity Provider
  4. Configure Shibboleth Identity provider SAML attributes
  5. Test the Shibboleth Identity Provider Single Sign-On configuration

Step 1: Get Metadata XML file from Shibboleth Identity Provider

  1. Locate Shibboleth metadata found at http://shibboleth.example.com/idp/shibboleth or in the Shibboleth Identity Provider filesystem in <install_folder>/shibboleth-idp/metadata.
  2. Modify Shibboleth metadata manually and ensure all user endpoints are uncommented (e.g., "SingleLogout").
  3. Save the XML file.

Step 2: Configure Single Sign-On in Jamf Pro

  1. In Jamf Pro, navigate to Settings > System Settings > Single Sign-On.
  2. Click Edit.
  3. Select the Jamf Pro Server checkbox to enable SSO.
  4. Select SSO options for your Jamf Pro server. Note: It is recommended that you copy the additional login URL to a secure location before continuing. In case of any configuration issues, you can use this URL to log back into Jamf Pro.
  5. For User Mapping: SAML, select "NameID" or specify a custom attribute. If using a custom attribute, the SAML assertion sent by the IdP must contain the NameID attribute (any value), in addition to the custom attribute, to complete the information exchange between Jamf Pro and the IdP.
  6. Select how users from your identity providers will be mapped to Jamf Pro users. By default, User Mapping: Jamf Pro is set to “Username”.
  7. Add the group attribute name.
  8. (Optional) Add the RDN Key for your LDAP group.
  9. Select Shibboleth for the Identity Provider.
  10. For Identity Provider Metadata Source, upload the metadata XML file downloaded in Step 1.
  11. Add the Entity ID used by your Jamf Pro server.
  12. (Optional) To sign requests to the Shibboleth Identity Provider or use Single Logout, generate or upload a Jamf Pro Signing Certificate.
  13. Save the configuration.

Step 3: Add a new Relying Party to Shibboleth Identity Provider

  1. Define "relying party" in the <install_folder>/conf/relaying-party.xml file. "c:relyingPartyIds" must include your Entity ID from Jamf Pro. Example:
     <bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'JamfPro','JamfPro2'}}">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO" p:encryptAssertions="never" p:signAssertions="never" p:encryptNameIDs="never" p:signResponses="never" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
            <ref bean="SAML2.Logout" />
                </list>
            </property>
        </bean>
  2. In Jamf Pro, navigate to Settings > System Settings > Single Sign-On and click Download Jamf Pro Metadata. You may also download the metadata from the Jamf Pro URL (i.e., "https://jss.example.com/saml/SSO").
  3. Create a new metadata provider in the <install_folder>/conf/metadata-providers.xml file. a. Specify your application ID (e.g., "Jamf Pro"). b. "metadataFile" attribute must point to a local copy of your Jamf Pro metadata. Example:
    <MetadataProvider id="JamfPro"  xsi:type="FilesystemMetadataProvider" metadataFile="/home/user/jss-metdata.xml"/>
    c. "MetadataProvider" can read metadata from the Jamf Pro URL. For more information see the Shibboleth Identity Provider documentation.
  4. Add a new attribute rule for your application in the <install_folder>/conf/attribute-filter.xml file. Example:
<AttributeFilterPolicy id="Jamf Pro">
        <PolicyRequirementRule xsi:type="Requester" value="JamfPro"/>
        <AttributeRule attributeID="eduPersonPrincipalName">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="uid">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
        <AttributeRule attributeID="mail">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
<AttributeRule attributeID="group">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
    </AttributeFilterPolicy

Step 4: Configure Shibboleth Identity Provider SAML attributes

  1. Navigate to the <install_folder>/conf/ldap.properties file. a. Depending on the User Mapping settings in Jamf Pro, LDAP should return the following attributes: "memberOf", "SamAccountName", or "UserPrincipalName". Example:
    idp.attribute.resolver.LDAP.returnAttributes    = displayName,mail,SamAccountName,memberOf,UserPrincipalName
  2. Update your attribute-resolver-ldap.xml file. The current configuration could be verified in <install_folder>/config/services.properties. a. Define an LDAP data connector. The default connector is defined in <install_folder>/conf/attribute-resolver-ldap.xml. Example:
   <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->


    <resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
        ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
        baseDN="%{idp.attribute.resolver.LDAP.baseDN}" 
        principal="%{idp.attribute.resolver.LDAP.bindDN}"
        principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
        useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:false}">
        <dc:FilterTemplate>
            <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
        </dc:FilterTemplate>
        <dc:ReturnAttributes>%{idp.attribute.resolver.LDAP.returnAttributes}</dc:ReturnAttributes>
        <dc:StartTLSTrustCredential id="LDAPtoIdPCredential" xsi:type="sec:X509ResourceBacked">
            <sec:Certificate>%{idp.attribute.resolver.LDAP.trustCertificates}</sec:Certificate>
        </dc:StartTLSTrustCredential>
    </resolver:DataConnector>

b. Add a new "group" attribute.
Example:

<resolver:AttributeDefinition xsi:type="ad:Simple" id="group" sourceAttributeID="memberOf">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="http://schemas.xmlsoap.org/claims/Group" friendlyName="group" encodeType="false" />
    </resolver:AttributeDefinition>

c. Configure SAML attributes for User Mapping. If Jamf Pro maps users by "NameID", configure the "NameID" attribute.

If the Jamf Pro User Mapping: Jamf Pro settings are set to "Username", set uid attribute source to "sAMAccountName".

Example:

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

If the Jamf Pro User Mapping: Jamf Pro settings are set to "Email", set uid attribute source to "mail" or "UserPrincipalName". If LDAP is configured in Jamf Pro, uid source must be set to the same LDAP attribute as the user attribute mapped in Jamf Pro.

Example:

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

If using a custom attribute in Jamf Pro, then add the appropriate attribute to the attribute-resolver-ldap.xml file. By default, Shibboleth provides attributes which you can use.

Step 5: Test the Shibboleth Identity Provider SSO configuration

To ensure Single Sign-On is set up correctly, do the following:

  1. Wait until Shibboleth Identity Provider applies new settings or restart the application server (i.e., "Tomcat").
  2. Log out of Jamf Pro.
  3. In a web browser, navigate to your Jamf Pro URL.
  4. Once redirected to the Shibboleth sign in page, enter your log in credentials. -If the test is successful, you will be logged in to Jamf Pro. -If the test failed, use your additional login URL to log in to Jamf Pro. The URL can be found in your Single Sign-On settings in Jamf Pro.

Additional Information

Like Comment
Order by:
SOLVED Posted: by psd_martinb

For my Shibboleth setup, I had to set signing responses on, and the JSS really wanted a nameID present.

In the config/relying-party.xml

<bean parent="SAML2.SSO" p:encryptAssertions="never" p:signAssertions="never" p:encryptNameIDs="never" p:signResponses="true" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>

After this, it works like a charm!

Like
SOLVED Posted: by baw128

In my setup, we found problems with the "User Mapping: SAML" options.
When selecting the "User Attribute" and customizing what key name to use from the existing Shibboleth data, it didn't work.

What we did was switch to the "NameID" option, then changed the Shibboleth servers to send the key we wanted but told it to name the key NameID before it was sent.

Like
SOLVED Posted: by nlopez

@baw128 I was having the same issue then out of desperation I tried the value of the "Name" attribute of the <saml2:Attribute> tag I wanted instead of the "FriendlyName" and it started working. So instead of "uid" I have "urn:oid:0.9.2342.19200300.100.1.1" in my SSO config.

Like
SOLVED Posted: by conadmin

anyone have issues with Self Service and SSO with shibboleth?

Like