Azure Partnership Remote Entity ID when Siteminder runs as SP
Article ID: 204004
Updated On:
Products
Issue/Introduction
When running Federation Services, can be defined more than 1 Partnership using the same Azure IdP Entity?
Resolution
At first glance, Federation integration with Azure is only supported when SiteMinder acts as IdP and Microsoft Azure acts as RP as per our documentation (1).
More, the same partnership can be defined (same IdP with same SP) when different entity IDs are in use. Microsoft Azure uses WS-FED. Note that the "Disambiguation ID" can be used in WS-FED to create several partnerships (2)(3).
But when running IdP on Microsoft Azure, that might not be feasible or applicable.
As such, as Microsoft Azure acts as IdP, get in touch with Microsoft to get guidance in that integration.
Note also that when defining the connection as WS-FED IP and RP, it won't let using SAML 2 token. This is expected. WS-FED is based on SAML 1.1. The WS-FED has a specific wrapped SAML2 token (4).
With more precision, the WS-FED brings a SAML 1.1 (5). When configuring the WS-FED protocol, use it as the WS-FED protocol is based on it.
There's no ACS in the WS-FED partnership. That's the reason for the Disambiguation ID feature (6).
On Siteminder local IDP, then for the same RP, configure different local IdP WS-FED entities with different Disambiguation IDs even if the URL is the same.
Finally, there's no possibility to configure Base URL multi-valued when defining entity ie SiteMinder as SP (7).
Additional Information
(1)
Single Sign-On to Microsoft Azure
Configure a WS-Federation partnership with Microsoft Azure.
In this partnership:
SiteMinder is the Identity Provider (IP)
Microsoft Azure is the Resource Partner (RP)
(2)
Can not create Partnership with Multiple times the same Remote IDP ID
For WSFED you can use the Disambiguation ID
(3)
Single Sign-On to Microsoft Azure
Disambiguation ID
Set this ID only when there are multiple partnerships between the
same IP and RP, and your company has separate business units with
their own relationship with Microsoft Azure.
Microsoft Azure uses a single ID to identify itself as an RP. CA
Single Sign-On does not allow multiple partnerships with the same
IP or RP ID. A disambiguation ID enables the system to
differentiate partnerships with a unique logical path suffix for
the service URLs given to a specific partner. Only one federation
service exists, but the suffix that is combined with the RP ID
creates a unique partnership lookup key.
Example: microsoftazure
The Disambiguation ID is appended to federation service URLs so
requests go to the correct remote partner.Example Requestor
Service URL:
https://fedserver1.forwardinc.com/affwebservices/public/wsfeddispatcher/microsoftazure
"microsoftazure" is the disambiguation ID.
Enter an alphanumeric string but do not use any special
characters.
(4)
On the other hand, WS-FED uses the SAML 2.0 but brings more
functionality.
(5)
ADFS Deep-Dive: Comparing WS-Fed, SAML, and OAuth
WS-FED
Token Type
ADFS will always issue a SAML 1.1 token
(6)
Single Sign-On to Microsoft Azure
Disambiguation ID
Set this ID only when there are multiple partnerships between the
same IP and RP, and your company has separate business units with
their own relationship with Microsoft Azure.
Microsoft Azure uses a single ID to identify itself as an RP. CA
Single Sign-On does not allow multiple partnerships with the same
IP or RP ID. A disambiguation ID enables the system to
differentiate partnerships with a unique logical path suffix for
the service URLs given to a specific partner. Only one federation
service exists, but the suffix that is combined with the RP ID
creates a unique partnership lookup key.
Example: microsoftazure
The Disambiguation ID is appended to federation service URLs so
requests go to the correct remote partner.Example Requestor
Service URL:
https://fedserver1.forwardinc.com/affwebservices/public/wsfeddispatcher/microsoftazure
"microsoftazure" is the disambiguation ID.
Enter an alphanumeric string but do not use any special
characters.
(7)
Specifies the base location of the server that is visible to the
intended users of the federation. This server is typically the
server where SiteMinder is installed. However, the server can be
the URL of the server that hosts federation services, such as the
Single Sign-on service. The base URL enables SiteMinder to generate
relative URLs in other parts of the configuration, making
configuration more efficient.
You can edit the Base URL. For example, you can configure virtual
hosts for the SiteMinder system. One virtual host handles the UI
communication. The other virtual host handles the user traffic that
the embedded Apache Web Server processes. You can edit the Base URL
to point only to the server and HTTP port of the Apache Web Server.
Value: valid URL
Feedback
