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 last request for the auth service host name, and it’d be the only one required to use Apache. Basically serve as a middle man, to pass requests to the idp, then lookup the data that’s supposed to be there from Shib, and provide that back to the app in one swoop. Is this reasonable? What’s the best approach to managing the Shib session? As it will set a cookie for the auth service host, not the app host, so I have thought about sticking the Shib session into the auth service session data to prevent the same user automatically getting authorized if they use another of our apps they may not have access to (i.e. I want don’t want the Shib session to work across app domains if a user has a session in one app and not the other). Almost every other week I feel there is an article about rolling auth wrong, so I just haven’t wanted to bother with it. So is my idea stupid? Is this an actual appropriate use for JWTs to store the Shib session id in while the auth service still will use cookies (with that JWT inside or an id to lookup that JWT)? Or should I use OAuth here? I can’t find any information that definitively describes my situation anyway, and every other article I read about setting up auth flows contradicts the one before it, or just says let the experts handle it or whatever, which unfortunately they apparently have been and the experience as dev sucks. Any information would be greatly appreciated, or just a definitive “it’s a stupid idea” would be appreciated as well so I can stop thinking about a world where I can use NGINX at work.
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.
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 last request for the auth service host name, and it’d be the only one required to use Apache. Basically serve as a middle man, to pass requests to the idp, then lookup the data that’s supposed to be there from Shib, and provide that back to the app in one swoop. Is this reasonable? What’s the best approach to managing the Shib session? As it will set a cookie for the auth service host, not the app host, so I have thought about sticking the Shib session into the auth service session data to prevent the same user automatically getting authorized if they use another of our apps they may not have access to (i.e. I want don’t want the Shib session to work across app domains if a user has a session in one app and not the other). Almost every other week I feel there is an article about rolling auth wrong, so I just haven’t wanted to bother with it. So is my idea stupid? Is this an actual appropriate use for JWTs to store the Shib session id in while the auth service still will use cookies (with that JWT inside or an id to lookup that JWT)? Or should I use OAuth here? I can’t find any information that definitively describes my situation anyway, and every other article I read about setting up auth flows contradicts the one before it, or just says let the experts handle it or whatever, which unfortunately they apparently have been and the experience as dev sucks. Any information would be greatly appreciated, or just a definitive “it’s a stupid idea” would be appreciated as well so I can stop thinking about a world where I can use NGINX at work.