I'm a SAML implementer and technical point of contact for a SP. I also have the unenviable duty of writing the "how to provision" documentation and doing our tech-rep training.
There are two kinds of IdP, in my experience: Microsoft's Active Directory / Federation Services (AD/FS) and everybody else.
"Everybody else" includes Ping Identity, which seems to be favored by very large companies. We also have a few users of the Computer Associates product and Okta. Other products we haven't seen yet in the wild include the Salesforce.com IdP and Onelogin. (Salesforce is interesting; they allow their instances to be provisioned as IdPs, SPs, or both.)
Almost everybody has been able to furnish Federation Metadata Endpoints to us; nobody has yet asked us for our Federation Metadata Endpoint data, which is good: we don't generate that.
AD/FS is a hassle. Typically of Ballmer-era Microsoft products, they changed the conceptual names of most of the protocol elements in their provisioning screens: they p*ssed on SAML until it smelt like them. So, I rewrote the docs for that IdP in Redmond Creole. Effective.
We have quite a few different AD/FS users; some from their Azure multitenant setup and others from on-premises AD / FS servers. Some multitenant AD/FS implementations provide multiple signing certificates in their federation metadata endpoints. Various Assertion xml-docs from them pick one of the multiple certs.
We implemented autoprovisioning, in which we create a profile on our service for any authenticated principal in a SAML Assertion we've never seen before. Some customers really like this as it gets rid of the need for upfront provisioning. But, I sure wish there were a standard deprovisioning protocol.
Chromium and Firefox both have nice SAML Web Extensions that render AuthnRequests and Assertions.
SAML is complicated and insanely hard to troubleshoot. But it's effective and seems (so far) to be secure.
I'm a SAML implementer and technical point of contact for a SP. I also have the unenviable duty of writing the "how to provision" documentation and doing our tech-rep training.
There are two kinds of IdP, in my experience: Microsoft's Active Directory / Federation Services (AD/FS) and everybody else.
"Everybody else" includes Ping Identity, which seems to be favored by very large companies. We also have a few users of the Computer Associates product and Okta. Other products we haven't seen yet in the wild include the Salesforce.com IdP and Onelogin. (Salesforce is interesting; they allow their instances to be provisioned as IdPs, SPs, or both.)
Almost everybody has been able to furnish Federation Metadata Endpoints to us; nobody has yet asked us for our Federation Metadata Endpoint data, which is good: we don't generate that.
AD/FS is a hassle. Typically of Ballmer-era Microsoft products, they changed the conceptual names of most of the protocol elements in their provisioning screens: they p*ssed on SAML until it smelt like them. So, I rewrote the docs for that IdP in Redmond Creole. Effective.
We have quite a few different AD/FS users; some from their Azure multitenant setup and others from on-premises AD / FS servers. Some multitenant AD/FS implementations provide multiple signing certificates in their federation metadata endpoints. Various Assertion xml-docs from them pick one of the multiple certs.
AD/FS has a convenient feature: its federation metadata is located at a standardized URL: https://federation.example.com/FederationMetadata/2007-06/Fe...
We implemented autoprovisioning, in which we create a profile on our service for any authenticated principal in a SAML Assertion we've never seen before. Some customers really like this as it gets rid of the need for upfront provisioning. But, I sure wish there were a standard deprovisioning protocol.
Chromium and Firefox both have nice SAML Web Extensions that render AuthnRequests and Assertions.
SAML is complicated and insanely hard to troubleshoot. But it's effective and seems (so far) to be secure.