I am looking into ADFS integration using Microsoft's OWIN WS-Federation package but I am finding it difficult to determine the purpose of certain parameters from the documentation that is available.
We have three environments, which are all hosted internally on a completely different system to the ADFS system we are trying to authenticate against.
From my research, I have a basic understanding of how the authentication process works but I could use some clarification on where these keywords fit into the Relying Party Trust configuration process, what they are used for and the relationships between them in order to better communicate what setup we need from the (third-party) owner of the ADFS system.
I understand that the wtrealm parameter corresponds to the app ID in the RPT but where does the WS-Federation URL come in? Is this the URL that the client will be redirected to to authenticate? In that case, do I need a separate RPT for each environment (dev, test, production)? What is the use case for multiple app IDs?
Any light shed on this would be very useful.
This is a confusing issue indeed. There are different standards (SAML, WSfed, OAuth) with their own terms for almost the same thing. These terms are used/confused instead/together in gateways (in a mixed way), causing mingling of terms.
Besides that, a configuration contains both (SAML Token) Issuer (IdP/IP for instance ADFS) properties and Application (SP/RP) properties. To add insult to injury, some people invent their own terminology in the hope that it clarifies things (and not the opposite).
Each party is worldwide uniquely identitfied by its EntityID
(in WSFed and SAML Metadata), must be a URI (URL is popular). It is (in WsFed) indeed the wtrealm=AppID
.
Besides that, each party has an EndPoint (URL, real address) where it offers functionality (for instance receiving a SAML Token). Federation URL is one of them. Depending on which configuration element you are talking about, it could be IP or RP.
Last but not least there are several (sometimes the same) certificates, one of which is for signing SAML Tokens and normally uniquely identifies (belongs to) the party (EntityID
).