Is it reasonable to use #Django + #drf , and #Keycloak for authn and authz ? Do I need another dependency like Django #allauth ? I see tutorial authors implementing BaseAuthentication from rest_framework.authentication (eg to plug in a JavaScript frontend). Is that enough to be secure? @adamchainz@adamghill any thoughts or a boost would be a gigantic help! 🙏
@blong@adamchainz@adamghill Hello! 👋 Adding in my two cents -- I think Django + DRF work well together (also never used allauth for APIs)
You can use custom DRF authentication classes, like you mentioned, to handle JWT validation/decoding along with user authentication, and lock down your endpoints with scope-based authz via custom DRF permissions if you need to! Hope that helps!
"Keycloak is an open source identity provider (IdP) with single-sign on (SSO) capabilities. It supports the most widely used enterprise authentication protocols, namely OpenID Connect (OIDC), OAuth 2.0, and SAML. With Keycloak, users sign in once and share the same identity across multiple applications and platforms in a transparent manner."
@ascherbaum Thank you, well recognized! We are currently in the final stages of creating a new website, which will of course also link to the Mastodon account!
Wer mag, kann bei den Chemnitzer Linuxtagen was über Single Sign-on für Webanwendungen von mir hören. Ist aber für die, die sonntags morgens nicht verschlafen. 😉
CVEs reported without version, and/or never updated to limit their CPEs to exclude versions where the vulnerability is fixed;
and now I get false positives every single time I update that dependency 😭
(in this case, specifically, Keycloak's CVE-2022-1438 and CVE-2023-0105, both still reported on version 22.0.4 by Dependency Track; the GitHub Advisories have the accurate information, but not the NVD 😡)
The last one is a payed service and has nothing to do with the open source captcha solution by the european union (despite the name nearly similar name)
If not secured properly, one-time passwords are a lot more likely to be guessed than you think!
Ever since I've learned that #Keycloak's default configuration does not prevent #OTP brute-forcing, I wanted to discuss the topic in detail and raise awareness.
There is a sea of Cloud Auth / Identity management providers.
There was a time I used to roll my own, but as security is getting complicated, it seems for startups & small to medium businesses it is better to use a cloud auth provider.
Please share your thoughts on your experience with this as I look into this area.
I could probably make a little shim between #IndieAuth clients and #Keycloak to handle client lookup and registration. Not completely sure how IndieAuth clients would handle the redirect though (as it would be undoubtedly cross-subdomain)...
I've started reading a bit about #IndieAuth -- for some reason, I started with the spec on W3.org, which makes more sense to me than a lot of stuff I've read but it also doesn't "feel" complete.
I'm wondering if I can configure #Keycloak to function sufficiently as an IndieAuth provider.
Keycloak doesn't work the way IndieAuth wants it to work. There don't seem to be any good providers that would work alongside it (again, I should be able to sign in just once!).
I could probably build and stand up a provider that uses Keycloak's OIDC and client registration mechanisms to make it work somewhat transparently, but that's quite a bit of technical work.
@anderseknert from my experience, not really - KAS is IMHO infact not used that often, but one needs to use it indirectly for configuring certain features like token-exchange or fine-grained permissions.
However, I more and more see keycloak combined with OPA/Zanzibar based stores e.g. Open FFA to enable flexible authz. IMHO this combination gives you the most flexibility at moderate cost.
@thomasdarimont thanks! Yeah, Keycloak for identity issuing JWTs and OPA verifying those and using the claims for policy decisions, that’s a power combo 😊