Having done this too many times and pulled out too much hair in frustration …
When you are asked to configure SAML access to application xxx owned by company yyy via ADFS v2.0, you need the following information.
If their SAML stack is a well-known product e.g. Ping, OpenAM, Oracle, simpleSAMLPHP … your life is suddenly orders of magnitude easier. You can follow the normal metadata (idp.xml, sp.xml) exchange.
If the words “home brewed” / “custom” / “proprietary” etc. are used, prepare for a load of pain.
SAML 1.1 or SAML 2.0?
IdP or SP initiated?
HTTP POST, Redirect or Artefact?
What SAML stack implementation do you use?
Is there an installation document?
If no document, what is …
- SP entity ID?
- https SAML endpoint?
- SAML subject NameID format e.g. UPN, email?
- What attribute do you expect to use for NameID e.g. UPN, email?
- What AD attribute is used to populate this?
Do you have the normal SAML metadata exchange protocol file?
Is the SP token required to be encrypted? Certificate?
Are AuthnRequests and Assertions expected to be signed? Certificate?
Single Logout (SLO) required?
SHA 1 or SHA 256?
The above can be configured via the normal ADFS screens.
There are others that require the AD FS 2.0 Cmdlets in Windows PowerShell. These are normally figured out by trial and error. In my experience, asking these types of questions just results in blank looks. You have to “suck it and see” as they say in Kiwiland!
e.g. if ADFS is the RP, then SamlResponseSignature may need to be changed.
This specifies the response signatures that the relying party expects. Valid values are AssertionOnly, MessageAndAssertion, and MessageOnly.
The default is AssertionOnly.