Separating User Database and Authorization from Apps with Istio and FusionAuth(reachablegames.com)
reachablegames.com
Separating User Database and Authorization from Apps with Istio and FusionAuth
https://reachablegames.com/oidc-fusionauth-istio/
6 comments
Hiya,
Disclosure: I work for FusionAuth.
> how do I easily have local development environments My team and I can use
A lot of our users use our docker container + kickstart to set up FusionAuth in a known state: https://fusionauth.io/docs/v1/tech/installation-guide/docker...
> displaying other users names and email addresses is a really common thing to need in applications I build
You can encode some information into the JWT. You don't want to put any super sensitive information, but email and username may be ok depending on your security posture. Then, when a service consumes a JWT (which it will be doing anyway, to ensure the user is authorized) it can extract the email, name and other info.
> how does one re-skin the sign up process or user management
As a sibling comment said, any IdP (identity provider) worth its salt will have the ability to skin login pages. Here's FusionAuth's docs on this: https://fusionauth.io/docs/v1/tech/themes/ but any other IdP should have similar docs
Hope this helps!
Disclosure: I work for FusionAuth.
> how do I easily have local development environments My team and I can use
A lot of our users use our docker container + kickstart to set up FusionAuth in a known state: https://fusionauth.io/docs/v1/tech/installation-guide/docker...
> displaying other users names and email addresses is a really common thing to need in applications I build
You can encode some information into the JWT. You don't want to put any super sensitive information, but email and username may be ok depending on your security posture. Then, when a service consumes a JWT (which it will be doing anyway, to ensure the user is authorized) it can extract the email, name and other info.
> how does one re-skin the sign up process or user management
As a sibling comment said, any IdP (identity provider) worth its salt will have the ability to skin login pages. Here's FusionAuth's docs on this: https://fusionauth.io/docs/v1/tech/themes/ but any other IdP should have similar docs
Hope this helps!
I'm less than an hour into an implementation of KeyCloak, but to answer your skinning question I ran across this "Keycloak Modern Theme" that you could buy, so I assume that skinning is definitely possible: https://keycloakthemes.com/themes/modern/
I'm the article author. Don't have all the answers. :-)
The appealing part for me was not reinventing the wheel for each application. Auth is hard to do well. Here's what I do know (to save you a search or two): - You definitely still want an application-level DB for you to have app-level features like showing friends/leaderboards/forum user names, etc. - Any decent auth system lets you skin the login forms however you want.
My guess about local dev is you skip the auth entirely and just force-feed the decoded JWT into the application. You can setup oauth2 using a hosts file to work properly, but it's a lot of work just to get to the decoded JWT to feed your app. YMMV.
Glad you found it interesting!
The appealing part for me was not reinventing the wheel for each application. Auth is hard to do well. Here's what I do know (to save you a search or two): - You definitely still want an application-level DB for you to have app-level features like showing friends/leaderboards/forum user names, etc. - Any decent auth system lets you skin the login forms however you want.
My guess about local dev is you skip the auth entirely and just force-feed the decoded JWT into the application. You can setup oauth2 using a hosts file to work properly, but it's a lot of work just to get to the decoded JWT to feed your app. YMMV.
Glad you found it interesting!
Be it Keycloak, Gluu, FusionAuth - I’m in total agreement to pull user management out of your app - even if you are a keeping things as simple as a rails monolith.
The cognitive overload of having to align PM’s, ops, internal support, etc with a custom solution is worth any of the downsides.
If you’d sat through any sprint planning or architecture exercise in a sizable org for auth, these can be a magic wand.
The cognitive overload of having to align PM’s, ops, internal support, etc with a custom solution is worth any of the downsides.
If you’d sat through any sprint planning or architecture exercise in a sizable org for auth, these can be a magic wand.
> The cognitive overload of having to align PM’s, ops, internal support, etc with a custom solution is worth any of the downsides.
That's a great point. You can just point at the IdP and say "this is what a user is, this is what a group is" and have the discussion wrapped up quickly. You're basically front-loading the user entity definition discussion to the evaluation phase (or, if your org has already chosen, offloading it to previously vetted solutions).
That's a great point. You can just point at the IdP and say "this is what a user is, this is what a group is" and have the discussion wrapped up quickly. You're basically front-loading the user entity definition discussion to the evaluation phase (or, if your org has already chosen, offloading it to previously vetted solutions).
My biggest mental hurdle with these systems are
- how do I easily have local development environments My team and I can use
- displaying other users names and email addresses is a really common thing to need in applications I build. What's the way to go about keeping that data in sync between the identity or auth system with the application? What used to be a database join could grow into any number of network requests to the identity server
- how does one re-skin the sign up process or user management to match each application so it's less jarring to the user?
I'm not really looking for answers - this isn't stack overflow :) They would come with even the smallest amount of investigation into it. I'm more just sharing what I think is an interesting mental block stopping me from immediately adopting it as the default.