Step 1:

Open the ADFS management application

Step 2:

Choose Enter data about the relying party manually and click Next.

Note: Skip the configure certificate option and click next.

Step 7:

In the Relying Party Trust identifier, enter the Entity ID of Service Desk Plus and click Add.

Click Next.

Step 8:
Under "Choose Access Control Policy Tab", select Permit Everyone and click next.

Step 9:
Skip the Ready to Add Trust by clicking next and under the Finish tab, click close.

Upon closing the tab, click the edit claim issuance policy.

Step 11:

Step 12:
Upon clicking the created relying party trust and click the properties.
The properties window will open.

Step 14:

Under the Advanced tab, choose the Algorithm used in ServiceDesk Plus.

Click Apply.

Step 15:
To download IDP certificate---> Go to Services > Certificates and click the Token-signing certificate.

Under the Details tab, click Copy to File. The Certificate Export Wizard opens.

• Choose DER encoded binary X.509 (.CER) and click Next.

• Enter the location to save the file and provide the file name at the end of the URL.

• Click Next. You must upload this certificate in ServiceDesk Plus application to complete the integration.

Unlike other IDPs, ADFS has a notably different way of sending claims. ADFS provides a few default claims (that are not sent, but just available for transformation or usage) and among which here are some notable ones:

• upn (conan@sdp-cart.com)

• implicitupn (conan@sdp-cart.com)

• name (SDP-CART\conan)

• windowsaccountname (SDP-CART\conan)

• insidecorporatenetwork (true)

• userip (10.59.8.239)

So, we can edit the "Claim Issuance Policy" and define a set of rules to transform any of the default claims or send additional claims from "Attribute Stores" like "Active Directory" or from a database.

Until now, we have been using the "Transform an Incoming Claim" rule to send the already available "Windows account name" claim's value (SDP-CART\conan) as the "Name ID" with "Transient" NameID format.

However to send additional claims, we can add either of the following rules to send the required properties.

• "Send LDAP Attributes as Claims"

• "Custom Rule"   

Send LDAP Attributes as claims:

ADFS already provides a set of "claim descriptions" in the URI format for a few common attributes (can be viewed from AD FS > Service > Claim Descriptions).  If we take a look at "UPN" field below, the value under "Claim Type" will be sent as the "claim name" and this is the value that needs to be mapped in SDP.

For every other attribute that they need, the users are expected to add new claim descriptions (either in URI format or normal string, say "seating_location" or "http://myOrg.com/SeatingLocation" for seating location). These descriptions can then be used in "Send LDAP Attributes as Claims" to send values from AD.

However, this forces the user to create separate claim descriptions for all the additional attributes they require (that does not exist in the default set provided by ADFS), which that may find hard.

However, "Send LDAP Attributes as Claims" also allows us to type the AD attribute name directly in the left side (like "physicalDeliveryOfficeName") and any arbitrary claim name (like "site" or "https://zylker.com/site") on the right, without having to define them under claim descriptions. Using this, we can easily send basic claims as well as claims for the UDFs.

Note: If their ADFS admin wants to maintain the standards and wishes to create claims for all attributes, they can certainly do that (either in URI format or as a normal string) and they can just update the claim description's "claim type" value in SDP.

 Limitations of Send LDAP Attributes: 

• As we know, we choose AD property on the left and we can type any "string" or type in a name of a "claim description" on the right. Also if we type a string, the string value will be the claim name, and if we type the name of a claim description, then the claim description's "claim type" (see image above) value will be sent as the claim name.

• So, If we want to send the upn of the user with the claim name as "UPN", we would type "UPN" on the right ride. However, since ADFS already has a claim description with the name "UPN", it will point to this claim description instead of our expected string (called "UPN"), and  eventually, the user's upn value will be sent with claim name as "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", instead of the expected string, "UPN".

• So we cannot use the claim names that are already defined in claim descriptions as "string".