vipyrsec / dragonfly

A combined C2 and malware scanning service focused on the early identification, analysis, and reporting of malicious packages on the Python Package Index
MIT License
0 stars 0 forks source link

Keycloak migration tracking issue #20

Open shenanigansd opened 10 months ago

shenanigansd commented 10 months ago

Tracking issue for migrating from Auth0 to selfhosted Keycloak

Robin5605 commented 10 months ago

keycloak :pleading_face:

shenanigansd commented 10 months ago

keycloak :pleading_face:

Link? Details? Pros/cons? (Of this vendor versus another vendor, not of the product itself)

Robin5605 commented 10 months ago

Keycloak Keycloak supports the client credentials flow with virtually an unlimited amount of clients (unlike Auth0) which is already an enticing choice for us. I'm not entirely able to compare Keycloak with any other products (only other similar vendor I can think of is FusionAuth, and I've barely looked into that at all) But Keycloak provides a central place to manage all our users, their permissions, and other settings we may need It's also beneficial to our ongoing RabbitMQ migration, since it does have an OAuth2 plugin) This way, we can use the same authentication server for both Mainframe and the message queue.

Those are just some of my initial thoughts, if anyone else has any vendors or suggestions I'm open to ideas.

Robin5605 commented 10 months ago

I've done some testing with Keycloak and the Dragonfly API, it's actually very easy to implement - the only things we have to change are the Auth0-vendored stuff, like the issuer and JWKs URL which is needed for validating tokens Those would have to be changed to a domain pointing at, say, keycloak.vipyrsec.com or auth.vipyrsec.com or something along those lines.

Getting Keycloak up and running on a local k8s cluster was also relatively easy, I'd be willing to PR the manifests if needed.

Robin5605 commented 10 months ago

The move to Keycloak has been approved per this comment on Discord