This reminded me of a question I’ve had, which is only tangentially related, but I’m hoping I’ll be able to get pointed in the right direction or told that the idea is stupid either is fine.
Login/Auth is one of the few areas that I have always just used whatever the standard library is for the platform because I don’t want to fuck it up, so I just have always gone with the tried and true sign in form -> server side sessions. I didn’t do anything more “advanced” until I started at the university I’ve worked out for a couple years now, and that’s still just been a SAML(?) request flow with our SSO (ugh) Shibboleth. If you’re lucky enough to be unfamiliar with Shib, it’s not that great, it does the job, but just barely while simultaneously holding our infrastructure hostage. I think SSO is great, but Shib (in our current architecture, and in my — potentially ignorant — opinion) is unnecessarily limiting while providing no real benefit. I’ve had an idea floating around in my head that could make it useful/less restrictive, since it’s not going to go away in lieu of something more modern, but I’m not sure if it makes sense/is secure/whatever. So, here’s my current issues with it.
Every web application that needs to use SSO at the university has to first send a request to the centralized authentication team — which consists solely of the creator of Shibboleth — this request is almost always sent back within 5 minutes with some condescending/snarky remark about how something wasn’t filled out correct, while also giving you the correction to be made, and told to submit it again (instead of just not being a dick and correcting it himself). Dealing with his shit attitude once a year or two l, I could handle, but my team is currently responsible for like 20-30 apps using SSO, and usually have to do this dance every at least once 2-3 months.
Once that’s over with and the app’s host name is now setup with the central idp. However, to utilize the idp, the app server requires the Shib service provider to execute the callback flow. Once again, wouldn’t be that awful if it weren’t for the fact that the Shib SP only officially supports 2 web servers Apache HTTPD and (I think) Tomcat or Jetty. An unofficial nginx plugin for Shib exists, but because we are “lucky” enough to have the Shib creator be the sole dictator of the SSO service, and nginx does not have his blessing (because fuck you, that’s why). Once again! I could deal with Apache, I prefer nginx, but ok I never have to actually manage Apache’s configs so it wouldn’t an issue, but it requires a version of Apache that doesn’t support shit like websockets.
However, what really makes it un enjoyable, is when it passes back the user auth info, it ACCORDING TO THE DOCS, should also include some additional data like the affiliations the user has, what departments they belong to, etc. What actually happens is outside of the users uid, it only reliably will give you their primary affiliation (staff/student/faculty) but not any others they may have. On the off chance you get the departments they belong to, they’re actually just numbers that correspond to a department — not the id commonly used by anything else which would be annoying but useful still — these numbers are seemingly only used by it, and nobody seems to have the full mapping(???). There’s a list of other useful attributes it supposed to return but nobody has ever seen it happen, lol. So now if an app wants to restrict itself to just certain departments/affiliations, it has to now check with another api or have that data piped into its DB from the central data store daily, to be able to do that. Among other things like not supporting sign out without jumping through hoops for every app that decides to let users sign out with a button, confusing documentation, and mountains of XML. It’s sucks.
My idea is to consolidate it into a single auth service for all my teams apps, as we’d just have to make on l...
I think if you setup something like keycloak with identity brokering, you can have shib sso as your Idp upstream and then turn around and manage downstream oauth resources from within keycloak. Perhaps cloud foundry's UAA is another option.
Typically additional attributes would need to be configured aka "released" by the IdP on a per-SP basis. I've also never heard of any specific server requirements when interfacing with Shibboleth. SAML is a standard and any generic library that supports SAML (e.g SimpleSAMLphp, saml2-js) can, in theory, work with Shibboleth. It sounds like there are other organizational/operational restrictions or requirements in place.
3 comments
[ 1.8 ms ] story [ 23.0 ms ] threadLogin/Auth is one of the few areas that I have always just used whatever the standard library is for the platform because I don’t want to fuck it up, so I just have always gone with the tried and true sign in form -> server side sessions. I didn’t do anything more “advanced” until I started at the university I’ve worked out for a couple years now, and that’s still just been a SAML(?) request flow with our SSO (ugh) Shibboleth. If you’re lucky enough to be unfamiliar with Shib, it’s not that great, it does the job, but just barely while simultaneously holding our infrastructure hostage. I think SSO is great, but Shib (in our current architecture, and in my — potentially ignorant — opinion) is unnecessarily limiting while providing no real benefit. I’ve had an idea floating around in my head that could make it useful/less restrictive, since it’s not going to go away in lieu of something more modern, but I’m not sure if it makes sense/is secure/whatever. So, here’s my current issues with it.
Every web application that needs to use SSO at the university has to first send a request to the centralized authentication team — which consists solely of the creator of Shibboleth — this request is almost always sent back within 5 minutes with some condescending/snarky remark about how something wasn’t filled out correct, while also giving you the correction to be made, and told to submit it again (instead of just not being a dick and correcting it himself). Dealing with his shit attitude once a year or two l, I could handle, but my team is currently responsible for like 20-30 apps using SSO, and usually have to do this dance every at least once 2-3 months.
Once that’s over with and the app’s host name is now setup with the central idp. However, to utilize the idp, the app server requires the Shib service provider to execute the callback flow. Once again, wouldn’t be that awful if it weren’t for the fact that the Shib SP only officially supports 2 web servers Apache HTTPD and (I think) Tomcat or Jetty. An unofficial nginx plugin for Shib exists, but because we are “lucky” enough to have the Shib creator be the sole dictator of the SSO service, and nginx does not have his blessing (because fuck you, that’s why). Once again! I could deal with Apache, I prefer nginx, but ok I never have to actually manage Apache’s configs so it wouldn’t an issue, but it requires a version of Apache that doesn’t support shit like websockets.
However, what really makes it un enjoyable, is when it passes back the user auth info, it ACCORDING TO THE DOCS, should also include some additional data like the affiliations the user has, what departments they belong to, etc. What actually happens is outside of the users uid, it only reliably will give you their primary affiliation (staff/student/faculty) but not any others they may have. On the off chance you get the departments they belong to, they’re actually just numbers that correspond to a department — not the id commonly used by anything else which would be annoying but useful still — these numbers are seemingly only used by it, and nobody seems to have the full mapping(???). There’s a list of other useful attributes it supposed to return but nobody has ever seen it happen, lol. So now if an app wants to restrict itself to just certain departments/affiliations, it has to now check with another api or have that data piped into its DB from the central data store daily, to be able to do that. Among other things like not supporting sign out without jumping through hoops for every app that decides to let users sign out with a button, confusing documentation, and mountains of XML. It’s sucks.
My idea is to consolidate it into a single auth service for all my teams apps, as we’d just have to make on l...