3 ms·

Interesting. I have used CAS extensively and was involved in building SAML support for a commercial app at one time. I didn't understand the post-binding thing

Interesting. I have used CAS extensively and was involved in building SAML support for a commercial app at one time. I didn't understand the post-binding thing really at all--CAS mostly uses the back channel method. My experience with SAML was that, not only was it a bear to get set up, the second client who wanted to use it was using a different SAML implementation and found things weren't as standardized as we had assumed. Both implementations supplied a principal, only one supplied an email address by default. I think it got sorted out after I left. I don't love CAS a lot, but it is a lot more turnkey than SAML. We're investigating JWT now, but I have a feeling it will turn out to be an implementation detail within a larger solution that we haven't even begun to conceive. I've also implemented shitty poor-man's federation on top of CAS. My recommendation there would be: don't do it. If you need federation CAS really can't help you, don't hack on it. The other thing I've learned is that none of these things is going to help you with authentication at all, and that tends to be something that isn't well thought-out before implementation time comes.

user5994461 10y ago
JWT = Json Web Token. That's not an authentication protocol at all. It's about using authentication tokens and JSON, which everyone's been already doing for years. SAML = Security & Authentication Mega cLusterfuck. It does get the job done, but it is the hell of a beast to understand and use.
- chris_wot 10y ago
  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.
vertex-four 10y ago
CAS is definitely useful for internal authentication - you have a database of users and a pile of apps. It's really easy to hack CAS authentication into almost any web app, and you can write a custom server if you like. It's significantly less useful for external authentication - where you want to your apps to auth against other people's user databases. SAML 2.0 is usually the standard for that, but as you say, it has to be configured properly on both ends.
- fusiongyro 10y ago
  I know, but you wind up doing what you're told to do even if it is stupid sometimes.

user5994461 10y ago

JWT = Json Web Token. That's not an authentication protocol at all. It's about using authentication tokens and JSON, which everyone's been already doing for years. SAML = Security & Authentication Mega cLusterfuck. It does get the job done, but it is the hell of a beast to understand and use.

chris_wot 10y ago
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.

vertex-four 10y ago

CAS is definitely useful for internal authentication - you have a database of users and a pile of apps. It's really easy to hack CAS authentication into almost any web app, and you can write a custom server if you like. It's significantly less useful for external authentication - where you want to your apps to auth against other people's user databases. SAML 2.0 is usually the standard for that, but as you say, it has to be configured properly on both ends.

fusiongyro 10y ago
I know, but you wind up doing what you're told to do even if it is stupid sometimes.