Download the latest version of Shibboleth IdP. You can refer to this download link.
Note: The configurations detailed below are just for reference. You can modify or add additional configurations as needed.
Configuring LDAP for authentication in Shibboleth IdP
Note: This article corresponds to the Shibboleth version V4.0.1
Shibboleth provides the option to configure authentication using LDAP. To create an LDAP directory for authentication, Download the ApacheDirectoryStudio from ApacheDirectoryDownloads.
Note: System Requirements: Java 11 should be installed, and the JAVA_HOME environment variable should be pointing to Java 11 installation.
For configuring a user in LDAP and creating a connection, follow the steps mentioned in this article.
Users can be created under the existing "system" dn, and the same can be configured in Shibboleth IDP as described below.
conf/ldap.properties contain the properties like connection URL, dn, authenticator, return attributes, etc., and these need to be configured for establishing the connection to LDAP in shibboleth. Refer to the source below for the changes to be made to the file. Cross-check in your file and make the relevant changes.
Note: anonSearchAuthenticator should not be used since it anonymously searches the user and does not work when the request is from a specific service.
#The authentication mechanism that is used to search the user in LDAP, bindSearchAuthenticator is the preferred one. idp.authn.LDAP.authenticator = bindSearchAuthenticator #LDAP connection URL idp.authn.LDAP.ldapURL = ldap://localhost:10389 #False for non secure connections idp.authn.LDAP.useStartTLS = false ipd.authn.LDAP.useSSL = false #Attributes that will be fetched from LDAP and returned to SP idp.authn.LDAP.returnAttributes = uid,mail,mobile,title,sn,telephoneNumber,o,givenName #DN in which the user is configured idp.authn.LDAP.baseDN = ou=system idp.authn.LDAP.subtreeSearch = true idp.authn.LDAP.userFilter = (uid={user}) idp.auth.LDAP.searchFilter = (uid=$resolutionContext.principal) #user identification(uid) and password idp.authn.LDAP.bindDN = uid=admin,ou=system idp.authn.LDAP.bindDNCredential = secret #Env variable to be used in other configuration xml files. idp.attribute.resolver.LDAP.ldapURL = %{idp.authn.LDAP.ldapURL} idp.attribute.resolver.LDAP.connectTimeout = %{idp.authn.LDAP.connectTimeout:PT3S} idp.attribute.resolver.LDAP.responseTimeout = %{idp.authn.LDAP.responseTimeout:PT3S} idp.attribute.resolver.LDAP.baseDN = %{idp.authn.LDAP.baseDN:undefined} idp.attribute.resolver.LDAP.bindDN = %{idp.authn.LDAP.bindDN:undefined} idp.attribute.resolver.LDAP.useStartTLS = %{idp.authn.LDAP.useStartTLS:true} #The below line should be commented, if we are using an unsecure connection #idp.attribute.resolver.LDAP.trustCertificates = %{idp.authn.LDAP.trustCertificates:undefined} idp.attribute.resolver.LDAP.searchFilter = (uid=$resolutionContext.principal) idp.attribute.resolver.LDAP.returnAttributes = %{idp.authn.LDAP.returnAttributes} idp.authn.LDAP.resolveEntryOnFailure = false
Rename conf/attribute-resolver.xml to conf/attribute-resolver-default.xml
Create attribute-resolver.xml file. Copy-paste the contents of conf/attribute-resolver-ldap.xml to attribute-resolver.xml and replace the content within the <AttributeResolver> tag.
Note: The conf/attribute-resolver.xml file is used to configure the mapping of the LDAP attributes and to establish the connection.
Note: The id and attributeNames configured to specify the LDAP directory attributes that need to be returned as part of the SAML response.
<AttributeResolver xmlns="urn:mace:shibboleth:2.0:resolver" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd"> <AttributeDefinition xsi:type="Simple" id="uid"> <InputDataConnector ref="myLDAP" attributeNames="uid"/> </AttributeDefinition> <AttributeDefinition xsi:type="Simple" id="mail"> <InputDataConnector ref="myLDAP" attributeNames="mail"/> </AttributeDefinition> <AttributeDefinition xsi:type="Simple" id="mobile"> <InputDataConnector ref="myLDAP" attributeNames="mobile"/> </AttributeDefinition> <AttributeDefinition xsi:type="Simple" id="title"> <InputDataConnector ref="myLDAP" attributeNames="title"/> </AttributeDefinition> <AttributeDefinition xsi:type="Simple" id="sn"> <InputDataConnector ref="myLDAP" attributeNames="sn"/> </AttributeDefinition> <AttributeDefinition xsi:type="Simple" id="telephoneNumber"> <InputDataConnector ref="myLDAP" attributeNames="telephoneNumber"/> </AttributeDefinition> <AttributeDefinition xsi:type="Simple" id="o"> <InputDataConnector ref="myLDAP" attributeNames="o"/> </AttributeDefinition> <DataConnector id="myLDAP" xsi:type="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:true}" exportAttributes="mail sn uid mobile title telephoneNumber o givenName"> <FilterTemplate> <![CDATA[ %{idp.attribute.resolver.LDAP.searchFilter} ]]> <!--<![CDATA[ (|(uid=$resolutionContext.principal)(mail=$resolutionContext.principal)) ]]>--> </FilterTemplate> <ReturnAttributes>%{idp.attribute.resolver.LDAP.returnAttributes}</ReturnAttributes> </DataConnector> </AttributeResolver>
The configuration to establish the connection should also be placed in the conf/attribute-resolver-ldap.xml. The exportAttributes property specifies the attributes to be fetched from LDAP and returned in SAML response.
<DataConnector baseDN="%{idp.attribute.resolver.LDAP.baseDN}" exportAttributes="mail sn uid mobile title telephoneNumber o givenName" id="myLDAP" ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}" principal="%{idp.attribute.resolver.LDAP.bindDN}" principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}" xsi:type="LDAPDirectory" useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}" > <FilterTemplate> <![CDATA[ %{idp.attribute.resolver.LDAP.searchFilter} ]]> <!--<![CDATA[ (|(uid=$resolutionContext.principal)(mail=$resolutionContext.principal)) ]]>--> </FilterTemplate> <ReturnAttributes>%{idp.attribute.resolver.LDAP.returnAttributes}</ReturnAttributes> </DataConnector>
The LDAP bindDN admin credential has to be updated in the credentials/secrets.properties (This file contains the credential information).
idp.authn.LDAP.bindDNCredential = secret idp.attribute.resolver.LDAP.bindDNCredential = %{idp.authn.LDAP.bindDNCredential:undefined}
authn/ldap-authn-config.xml file deals with the overall LDAP authentication configurations. Cross-check the following tag with the values shown below:
<bean id="shibboleth.authn.LDAP.returnAttributes" parent="shibboleth.CommaDelimStringArray"> <constructor-arg type="java.lang.String" value="%{idp.authn.LDAP.returnAttributes:*}" /> </bean>
The attributes to be returned should also be mentioned in conf/attribute-filter.xml. Create <AttributeFilterPolicy> inside <AttributeFilterPolicyGroup> tag similar to below content.
<AttributeFilterPolicy id="example3"> <PolicyRequirementRule xsi:type="ANY"/> <AttributeRule attributeID="uid" permitAny="true"/> <AttributeRule attributeID="mail" permitAny="true"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="cn" permitAny="true"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="sn" permitAny="true"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="mobile" permitAny="true"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="title" permitAny="true"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="telephoneNumber" permitAny="true"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="o" permitAny="true"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> <AttributeRule attributeID="givenName" permitAny="true"> <PermitValueRule xsi:type="ANY"/> </AttributeRule> </AttributeFilterPolicy>
The password authentication configuration using LDAP requires the following changes in authn/password-authn-config.xml. Please make the other two options as comments when using LDAP.
<!--<import resource="jaas-authn-config.xml" /> <import resource="krb5-authn-config.xml" />--> <import resource="ldap-authn-config.xml" />
Note: Refer to the LDAP Configuration Reference Link for more details on LDAP configuration for Shibboleth IDP
Configuring SAML SSO with Shibboleth IDP
Note: We have included two ways through which you could achieve a smooth configuration. 'Approach 1' is a video-based guide and 'Approach 2' is a text-based guide.
Approach 1: Video tutorial
Approach 2: A step-by-step guide
Login to your Freshworks account using your Organization URL that will look something like this: yourcompany.freshworks.com (or yourcompany.myfreshworks.com).
Under Security, you can enable SSO (under default login method or custom policies) and choose Shibboleth as the SSO you want to set up. We have provided helpful configuration guides within the UI.
Map information from the IdP
Entity ID
Copy the entity id value from conf/idp.properties or metadata/idp-metadata.xml and paste it in the field. In the idp.properties file, the entity id value has to be configured based on the host we run the IdP.
E.g., <your_shibboleth_URL>/idp/shibboleth
SAML SSO URL
From the metadata/idp_metadata.xml file, copy the location attribute value of SingleSignOnService with HTTP-Redirect binding (We support only HTTP-Redirect Binding) and paste it to the SAML SSO URL field in the Freshworks screen.
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" req-attr:supportsRequestedAttributes="true" Location="<your_shibboleth_URL>/idp/profile/SAML2/Redirect/SSO"/>
Note: Update the host/domain and port information accordingly in the metadata/idp_metadata.xml file for all the URL mappings.
Signing Options
Choose the signing option of your choice. By default, the value will be set to Signed Response. Any additional configurations can be done as required in idp configuration files: conf/idp.properties, and conf/relying-party.xml
p:signAssertions attribute determines the assertion signing behavior when idp.saml.honorWantAssertionsSigned=false. When true, the decision to sign assertions is taken from WantAssertionsSigned property of SP metadata.
p:signResponses attribute determines the response signing behavior solely. The default value is true.
conf/idp.properties # When true, the decision to sign assertions is taken from WantAssertionsSigned property of SP metadata. # When false, the decision to sign assertions is taken from the p:signAssertions property of relying-party.xml # true is the default and recommended value. idp.saml.honorWantAssertionsSigned=true conf/relying-party.xml <util:list id="shibboleth.RelyingPartyOverrides"> <!-- The following bean would override the default behaviour of IDP and configure the specific properties for signingAssertions, signingResponses and encryptAssertions. relyingPartyIds=Entity ID of SP SAML2.SSO profile determines the configurations used for Sign in p:signAssertions attribute determines the assertion signing behaviour when idp.saml.honorWantAssertionsSigned=false p:signResponses attribute determines the response signing behaviour solely. Default value is true. SAML2.Logout profile determines the configurations of Log out --> <bean id="ExampleSP" parent="RelyingPartyByName" c:relyingPartyIds="<Service Provider(SP) Entity Id>">. <property name="profileConfigurations"> <list> <bean parent="SAML2.SSO" p:signAssertions="false" p:encryptAssertions="true" p:signResponses="true"/> <bean parent="SAML2.Logout" p:signResponses="true" /> </list> </property> </bean> </util:list>
Note: The changes made in the relying party config file will be checked periodically at an interval configured in idp.service.relyingparty.checkInterval of conf/services.properties.
idp.service.relyingparty.checkInterval = PT3SFor more details, please refer to the relying party config in RelyingPartyConfigurationWiki. For SAML2.SSO profile configuration, please refer to SAML2SSO Profile Config.
Security Certificate
The certificate value can be taken from the xml tag <KeyDescriptor use="signing"> in metadata/idp-metadata.xml file. There will be two certificates with this tag. Please copy the second one and paste it into the relevant field. The first one is for back-channel configuration, and the second one is for front-channel configuration.
Map information to the IdP
Save the SSO configuration and then click on Download Metadata to download the SP metadata.
Move the downloaded file to a location, say /opt/shibboleth-idp/metadata/<downloaded_metadata_file.xml>, and configure this path in the backingFile attribute of conf/metadata-providers.xml.
Shibboleth provides various types to configure the metadata paths, one of which is FileBackedHTTPMetadataProvider. This type would initially fetch the metadata from the backingFile system location and then periodically hit the SP's metadata endpoint to refresh it. The periodic delay in which the IDP should hit the metadata endpoint is configured using the attributes: minRefreshDelay, maxRefreshDelay, refreshDelayFactor, and backupFileInitNextRefreshDelay, as shown below:
<MetadataProvider id="HTTPMetadata"
xsi:type="FileBackedHTTPMetadataProvider" minRefreshDelay="PT30S" maxRefreshDelay="PT30S" refreshDelayFactor="0.125"
disregardTLSCertificate="true"
backingFile="/opt/shibboleth-idp/metadata/<downloaded_metadata_file.xml>"
metadataURL="<Service Provider(SP) Entity Id>"
backupFileInitNextRefreshDelay="PT30S">
<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P30D"/>
<MetadataFilter xsi:type="EntityRoleWhiteList">
<RetainedRole>md:SPSSODescriptor</RetainedRole>
</MetadataFilter>
</MetadataProvider>The details about these attributes can be found here.
FilesystemMetadataProvider type would only read the metadata from the system location, and hence the changes are done on the SP side (Freshworks) will not be read further.
FilesystemMetadataProvider source
<MetadataProvider id="LocalMetadata" xsi:type="FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/<downloaded_metadata_file.xml>"/>Hence FileBackedHTTPMetadataProvider is the preferred type.
The authentication in the Freshworks application will be done using the emailAddress associated with the uid of the LDAP user.
This corresponding mapping has to be done in conf/saml-nameid.xml, inside the <util:list id="shibboleth.SAML2NameIDGenerators"> tag.
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
p:omitQualifiers="true"
p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
p:attributeSourceIds="#{ {'mail'} }" />Advanced Option (Optional)
Encrypted Assertion
If assertion in SAML response has to be encrypted, you can enable this option. A public key and private key will be generated for encryption, and Shibboleth can read the public key from the SP metadata.
The behavior of the encrypted assertion varies based on 2 properties.
idp.encryption.optional in conf/idp.properties. The default value is false. We recommend that you set it to true.
p:encryptAssertions in conf/relying-party.xml. We recommend that you set it to true.
Authn Requests Signed
It is the user's choice to enable or disable this feature. Enabling this option will send a signature along with the SAML authn requests. Shibboleth reads the WantAuthnRequestsSigned property from metadata and behaves accordingly.
3. SAML Signature Method
The SAML Signature method is used to specify the signature algorithm that is to be used for signing the SAML assertions and responses. Shibboleth supports SHA256 and SHA1 algorithm to create its signing certificates.
4. SAML Single Logout
Enabling this feature would log out the user from IdP when the user logs out in SP (Freshworks). Map the location attribute of <SingleLogoutService> tag corresponding to HTTP-Redirect binding to the SLO URL field. We choose HTTP-Redirect binding since we send the SLO request in the redirect GET method.
SLO Config
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="<your_shibboleth_URL>/idp/profile/SAML2/Redirect/SLO"/>
Note: When 3rd party cookies are blocked, only the IdP session will be terminated, and the SP session will be unaffected. To avoid this, we have to allow cookies corresponding to the freshworks domain. Steps to enable "freshworks.com/myfreshworks" cookies when 3rd party cookies are blocked:
Open Chrome Settings. Under the Privacy and Security tab, click on "Cookies and other site data."
Add [*.]freshworks.com or [*.]myfreshworks.com accordingly in the "Sites that can always use cookies" section.
After adding the cookies, if we try the SLO option, the SP session will also be terminated along with the IdP session.
The following property in conf/idp.properties must be enabled to support the SLO propagation feature.
conf/idp.properties
# Track information about SPs logged into
idp.session.trackSPSessions = true
# Support lookup by SP for SAML logout
idp.session.secondaryServiceIndex = trueThe following page will be displayed after successful logout, and the services in which the session is terminated will also be listed.
For more details on logout configuration, please refer to LogoutConfiguration, LogoutConfigurationofIDPV3 documentation.
Profile Attributes Sync
Enabling this feature will sync the profile attributes like givenname, surname, phone, mobile, company, title, etc., from the IdP configurations to SP every time a user logs in using SSO. We expect the profile attributes to be in one of the formats mentioned below:
In Shibboleth IDP, the mapping of attributes can be done using the schema-specific xml files based on the schema used in LDAP. conf/attributes/inetOrgPerson.xml corresponds to inetOrgPerson schema in LDAP.
Profile Attribute Mapping source:
<bean parent="shibboleth.TranscodingRuleLoader">
<constructor-arg>
<list>
<bean parent="shibboleth.TranscodingProperties">
<property name="properties">
<props merge="true">
<prop key="id">givenName</prop> //The value in "id" property will be the one used in LDAP Directory configuration.
<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
<!--<prop key="saml2.name">urn:oid:2.5.4.42</prop>--> //This will be the default mapping used. Kindly replace this with the below line.
<prop key="saml2.name">givenname</prop>
<prop key="saml1.name">urn:mace:dir:attribute-def:givenName</prop>
<prop key="displayName.en">Given name</prop>
<prop key="description.en">Given name of a person</prop>
<!-- Other lang entries can be added as per requirement -->
</props>
</property>
</bean>
<bean parent="shibboleth.TranscodingProperties">
<property name="properties">
<props merge="true">
<prop key="id">mail</prop>
<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
<!--<prop key="saml2.name">urn:oid:0.9.2342.19200300.100.1.3</prop>--> //This will be the default mapping used. Kindly replace this with the below line.
<prop key="saml2.name">email</prop>
<prop key="saml1.name">urn:mace:dir:attribute-def:mail</prop>
<prop key="displayName.en">E-mail</prop>
<prop key="description.en">E-Mail: Preferred address for e-mail to be sent to this person</prop>
<!-- Other lang entries can be added as per requirement -->
</props>
</property>
</bean>
<bean parent="shibboleth.TranscodingProperties">
<property name="properties">
<props merge="true">
<prop key="id">mobile</prop>
<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
<!--<prop key="saml2.name">urn:oid:0.9.2342.19200300.100.1.41</prop>--> //This will be the default mapping used. Kindly replace this with the below line.
<prop key="saml2.name">mobile</prop>
<prop key="saml1.name">urn:mace:dir:attribute-def:mobile</prop>
<prop key="displayName.en">Mobile phone number</prop>
<prop key="description.en">Mobile phone number</prop>
<!-- Other lang entries can be added as per requirement -->
</props>
</property>
</bean>
<bean parent="shibboleth.TranscodingProperties">
<property name="properties">
<props merge="true">
<prop key="id">o</prop>
<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
<!--<prop key="saml2.name">urn:oid:2.5.4.10</prop>-->
<prop key="saml2.name">organization</prop>
<prop key="saml1.name">urn:mace:dir:attribute-def:o</prop>
<prop key="displayName.en">Organization name</prop>
<prop key="description.en">Organization name</prop>
<!-- Other lang entries can be added as per requirement -->
</props>
</property>
</bean>
<bean parent="shibboleth.TranscodingProperties">
<property name="properties">
<props merge="true">
<prop key="id">sn</prop>
<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
<!--<prop key="saml2.name">urn:oid:2.5.4.4</prop>-->
<prop key="saml2.name">surname</prop>
<prop key="saml1.name">urn:mace:dir:attribute-def:sn</prop>
<prop key="displayName.en">Surname</prop>
<prop key="description.en">Surname or family name</prop>
<!-- Other lang entries can be added as per requirement -->
</props>
</property>
</bean>
<bean parent="shibboleth.TranscodingProperties">
<property name="properties">
<props merge="true">
<prop key="id">telephoneNumber</prop>
<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
<!--<prop key="saml2.name">urn:oid:2.5.4.20</prop>-->
<prop key="saml2.name">phone</prop>
<prop key="saml1.name">urn:mace:dir:attribute-def:telephoneNumber</prop>
<prop key="displayName.en">Business phone number</prop>
<prop key="description.en">Business phone number: Office or campus phone number</prop>
<!-- Other lang entries can be added as per requirement -->
</props>
</property>
</bean>
<bean parent="shibboleth.TranscodingProperties">
<property name="properties">
<props merge="true">
<prop key="id">title</prop>
<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
<!--<prop key="saml2.name">urn:oid:2.5.4.12</prop>-->
<prop key="saml2.name">title</prop>
<prop key="saml1.name">urn:mace:dir:attribute-def:title</prop>
<prop key="displayName.en">Title</prop>
<prop key="description.en">Title of a person</prop>
<!-- Other lang entries can be added as per requirement -->
</props>
</property>
</bean>
<bean parent="shibboleth.TranscodingProperties">
<property name="properties">
<props merge="true">
<prop key="id">uid</prop>
<prop key="transcoder">SAML2StringTranscoder SAML1StringTranscoder</prop>
<!--<prop key="saml2.name">urn:oid:0.9.2342.19200300.100.1.1</prop>-->
<prop key="saml2.name">uid</prop>
<prop key="saml1.name">urn:mace:dir:attribute-def:uid</prop>
<prop key="displayName.en">User ID</prop>
<!-- Other lang entries can be added as per requirement -->
<prop key="description.en">A unique identifier for a person, mainly used for user identification within the user's home organization.</prop>
<!-- Other lang entries can be added as per requirement -->
</props>
</property>
</bean>
</list>
</constructor-arg>
</bean>For an attribute to be returned in the SAML response to SP, it must be configured in the files mentioned in the LDAP configuration.
Note:
On completing the configurations, start the Jetty server and then try signing in with SSO for the configured authentication module.
The Shibboleth user validation page will be displayed. Enter the credentials configured in the LDAP.
On successful validation, you will be taken to the dashboard page.
IdP Initiated Single Sign-On
- IdP initiated flow can be checked using the URL given below that can be configured with the entity ID and relay state.
IDP Initiated SSO URL
<your_shibboleth_URL>/idp/profile/SAML2/Unsolicited/SSO?providerId=<Service Provider(SP) Entity Id>&target=<relay_state URL<
- On hitting this URL, it will take us to the login page and after authentication, we will be redirected to the relay state configured. (should be a URL encoded value in the query param.
Relay state(target) param is optional and, if left empty, will take us to the organization dashboard
Please refer to this Shibboleth Wiki Link for more details
IDP Initiated Single Logout
The logout endpoint for the IdP initiated flow is <your_shibboleth_URL>/idp/profile/Logout
This endpoint has to be hit by using the idp cookies: shib_idp_session and JSESSIONID
The JSESSIONID and shib_idp_session cookie values can be fetched from the subsequent IdP calls in the login flow.
cURL for IDP Initiated Logout
curl --location --request GET '<your_shibboleth_URL>/idp/profile/Logout' \
--header 'Cookie: JSESSIONID=node0uzt3h0pqggs21ssypyfatxb5d3.node0; shib_idp_session=3c3a371dd27b092a50a885645e11f8fcfeab903dce3f313b00ba641d0d9e6c65’
On hitting the IDP logout endpoint, it would take you to a page that shows 2 options
Logout locally - terminates only the IdP session
Logout globally - terminates all the sessions associated with the IdP session.
