000021456 - How is a target URL mapped to a trusted RP (Relying Party) in RSA Federated Identity Manager (FIM) 2.5?

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000021456
Applies ToRSA Federated Identity Manager (FIM) 2.5
IssueHow is a target URL mapped to a trusted RP (Relying Party) in RSA Federated Identity Manager (FIM) 2.5?
CauseSuppose, for example, given a target URL "http://www.rsa.net" and defined relying parties: "http://rp.na.rsa.net", "http://rp.rsa.net", "http://rp.bedford.na.rsa.net", and "http://au.rsa.net", what would be the order of relying parties in the sorted list, and what would the default Target URL plugin return as mapped to "http://www.rsa.net"?
Resolution
The trusted RPs would actually be sorted as follows:

http://au.rsa.net
http://rp.rsa.net
http://rp.na.rsa.net
http://rp.bedford.na.rsa.net
 
Note that the domains with the fewest number of fragments come first (?au.rsa.net? and ?rp.rsa.net? have 3 pieces) and domains with the most come last (?rp.bedford.na.rsa.net? has 5 pieces). When domains have the same number of fragments, they are sorted alphabetically by the first differing piece (in this case ?au? comes before ?rp?, for example).
The default target mapper will first look for a match to ?www.rsa.net? and find none. Then it will lose the ?www? and look for a match for ?rsa.net?. It will find ?http://au.rsa.net? first and that?s the one it will use.

More Examples:

The best way to explain how FIM?s default target mapper works is by detailing a few examples. Given a set of 6 trusted RPs (see the ARS/ACS URLs below), how is a provided target URL used to determine which trusted RP will be sent an assertion?

http://rp1.rsa.com:7001/samlrelyingparty/RP        (FQDN: rp1.rsa.com)
http://rp2.rsa.com:7001/samlrelyingparty/RP        (FQDN: rp2.rsa.com)
http://rp3.na.rsa.com:7001/samlrelyingparty/RP    (FQDN: rp3.na.rsa.com)
http://rp4.na.rsa.com:7001/samlrelyingparty/RP    (FQDN: rp4.na.rsa.com)
http://rp5.rsa.net:7001/samlrelyingparty/RP          (FQDN: rp5.rsa.net)
http://rp6.na.rsa.net:7001/samlrelyingparty/RP     (FQDN: rp6.na.rsa.net)
 
Example 1:
Target URL: http://rp1.rsa.com/home.html (FQDN: rp1.rsa.com)
RP1 (http://rp1.rsa.com:7001/samlrelyingparty/RP) will be selected. Why? Because the default target mapper will ALWAYS select the RP that has an FQDN identical to that of the target URL, if one exists.

Example 2:
Target URL: http://www.rsa.com/home.html (FQDN: www.rsa.com)
RP1 (http://rp1.rsa.com:7001/samlrelyingparty/RP) will be selected. Why? Because the default target mapper will recognize that both RP1 and RP2 have the closest-matching FQDNs.  The first part of the domain name (moving from right to left) that does not match (in this case, ?www? does not match ?RP1? or ?rp2?) is used to order the matching RPs alphabetically.  The string ?RP1? comes before ?rp2?, so RP1 is going to be chosen here.

Example 3:
Target URL: http://www.na.rsa.net/home.html (FQDN: www.na.rsa.net)
RP6 (http://rp6.na.rsa.net:7001/samlrelyingparty/RP) will be selected. Why? Because the default target mapper will match as much of the target URL FQDN as possible. It won?t settle on one RP5 even though its FQDN ends in ?rsa.net? because RP6 ends in ?na.rsa.net?, which means it has more in common with the FQDN of the target URL.
NOTE: If RP6 did not exist, RP5 would be used.
 
Example 4:
Target URL: http://www.google.com/home.html (FQDN: www.google.com)
An error will occur (i.e. no RP will be selected). Why? Because the default target mapper will not find a match, period. The FQDN of the target URL has no common domain with any of the defined RPs (?com? does not count - it is not a domain).


Essentially, the default target mapper attempts to match as much of the FQDN of the target URL as possible. Only when more than one trusted RP matches to the same degree does the target mapper choose one based on some fairly arbitrary, but predictable, metric (in this case, alphabetical order of the domain name fragment).
Legacy Article IDa23030

Attachments

    Outcomes