
Login and Authentication Workflows - mooreds
https://fusionauth.io/learn/expert-advice/authentication/login-authentication-workflows
======
cutety
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.

~~~
carus
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.

