Is Keycloak a good option if I want to setup a SAML Service Provider using user records from my own MySQL database? I've looked at Okta and Keycloak and it's not really obvious to whether I'm supposed to give up my User table and let the auth system handle it, or whether the user data ends up being spread between my DB and the auth system (I think that's how Okta would be implemented).
I know I could roll my own with PassportJS or something, but I'd like all the nice Okta stuff (MFA, password policies, SAML SSO, maybe federation) but integrated with my existing DB. Or is that just too much to ask?
Are you asking if you can use Keycloak with your own user table? Typically these identity providers want to own the user, so would expect you to port the user info, including password hashes, into them.
If you have data that is user related but not auth related (application specific data), I've seen a few patterns:
* Push it all into the auth provider. Not sure about keycloak, but some providers have the ability to store arbitrary data (a blob, basically) about a user.
* Create a table in your database with an identifier provided by Keycloak, preferably an immutable one. Then when a user logs in, you can find their identifier, then look up the application specific data.
If you want to have all PII in one place, the former option is best. If you want to maximize your flexibility, the latter is what I'd suggest.
If you want to keep the user data in your database, I'd look at a library (as you suggest). It's a different class of solution than a standalone auth provider like Keycloak.
> Are you asking if you can use Keycloak with your own user table?
Yes, that's what I'm asking. Because my User table has relationships with the rest of my database, and I want to keep that (user X owns application-item Y; User X created Comment Z on application-item Y, etc... you get it).
> Create a table in your database with an identifier provided by Keycloak, preferably an immutable one. Then when a user logs in, you can find their identifier, then look up the application specific data.
This looks like a good option to me. I'd be fine with PII in Keycloak, and app-specific stuff in my database, provided there's a solid link between the two. If the user wants to change their email, that goes into Keyclock, and if they do something else that is connected to the application function that goes into the app DB.
I know I could roll my own with PassportJS or something, but I'd like all the nice Okta stuff (MFA, password policies, SAML SSO, maybe federation) but integrated with my existing DB. Or is that just too much to ask?