3 ms·

I just don't think it's documented all that well. Aside from Wikipedia, where on earth do go to learn how the drafted thing is meant to work? It seems to have m

I just don't think it's documented all that well. Aside from Wikipedia, where on earth do go to learn how the drafted thing is meant to work? It seems to have multiple profiles, and I can't find a decent article about SAML artifacts anywhere...

user5994461 10y ago
You can get the SAML spec, it's a standard distributed by oasis, last I checked. It will help you a bit. Then you will only have two majors issues. 1) The protocol is a really complex beast of giant XML messages, with many variants of workflows. 2) It's very modular to allow to interface with lots of stuff with custom authentication, custom attributes, custom systems. So there is only 50% of a protocol which is clearly "standardized", the other 50% are left as a specific use case details with limited practical example. I'm a believer that one doesn't do or understand SAML. It's more like, you get two specific products that needs to authenticate together for the business. You read the integration documentation for both and try to find whatever micro-subset of protocol they both talk and make it interface.
vertex-four 10y ago
The artifact resolution profile is in here: https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf https://www.oasis-open.org/committees/download.php/56782/sst... And the HTTP artifact resolution binding (a complete, start-to-finish, description of what you need to do to log in a user to SAML and get attributes about them) is in here: https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf https://www.oasis-open.org/committees/download.php/56779/sst... Those come from here: https://wiki.oasis-open.org/security/FrontPage https://wiki.oasis-open.org/security/FrontPage Frankly, though... you're usually not supposed to be implementing this stuff yourself. Put Shibboleth's mod_shib_24.so in Apache in front of your login endpoint, and it behaves as a SAML service provider for you with consistent configuration and lots of help available for when it breaks. It provides you with HTTP headers for all the attributes provided about the user. If you're not using Apache for most of your app, you could just use it for a login script which shoves everything into a cookie. Of course, if you're developing ASP.Net for Windows, you get your sysadmin to throw up an ADFS instance which deals with the federation, then use the built-in libraries to auth against ADFS, and it all works like magic.

user5994461 10y ago

You can get the SAML spec, it's a standard distributed by oasis, last I checked. It will help you a bit. Then you will only have two majors issues. 1) The protocol is a really complex beast of giant XML messages, with many variants of workflows. 2) It's very modular to allow to interface with lots of stuff with custom authentication, custom attributes, custom systems. So there is only 50% of a protocol which is clearly "standardized", the other 50% are left as a specific use case details with limited practical example. I'm a believer that one doesn't do or understand SAML. It's more like, you get two specific products that needs to authenticate together for the business. You read the integration documentation for both and try to find whatever micro-subset of protocol they both talk and make it interface.

vertex-four 10y ago

The artifact resolution profile is in here: https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata-2.0-wd-07.pdf https://www.oasis-open.org/committees/download.php/56782/sst... And the HTTP artifact resolution binding (a complete, start-to-finish, description of what you need to do to log in a user to SAML and get attributes about them) is in here: https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata-2.0-wd-06.pdf https://www.oasis-open.org/committees/download.php/56779/sst... Those come from here: https://wiki.oasis-open.org/security/FrontPage https://wiki.oasis-open.org/security/FrontPage Frankly, though... you're usually not supposed to be implementing this stuff yourself. Put Shibboleth's mod_shib_24.so in Apache in front of your login endpoint, and it behaves as a SAML service provider for you with consistent configuration and lots of help available for when it breaks. It provides you with HTTP headers for all the attributes provided about the user. If you're not using Apache for most of your app, you could just use it for a login script which shoves everything into a cookie. Of course, if you're developing ASP.Net for Windows, you get your sysadmin to throw up an ADFS instance which deals with the federation, then use the built-in libraries to auth against ADFS, and it all works like magic.