4 ms·

I recently implemented some code to: Sign into an account using username/password/MFA, authenticate with an API using OAuth to get a SAML assertion, authenticat

by foxyv 3y ago

I recently implemented some code to: Sign into an account using username/password/MFA, authenticate with an API using OAuth to get a SAML assertion, authenticate with another API using the SAML assertion to get a token, then sign into an API using the token... Why do we do this to ourselves?

jeroenhd 3y ago
Not having to deal with auth yourself makes your life so much easier. For my self hosted stuff, I've out a simple OIDC requirement in my Apache config (https://github.com/OpenIDC/mod_auth_openidc https://github.com/OpenIDC/mod_auth_openidc) and have set up a plain Keycloak server (should've gone with something simpler but oh well). Apache now sets the user ID in a header (that doesn't get passed on from the client for obvious security reasons) and all the application on the other end needs to do is look up the user ID. Multi factor authentication, password recovery, session expiration and everything else is all handled by Keycloak and no unauthenticated requests can make it through Apache. Tokens are signed and verified, of course, so there's no faking anything. I think Caddy has a similar system built in, including a login page and everything. Give or six lines of config are all you need to handle authentication, plus you get automatic security updates for your authentication flow in case something happens. There's a reason Okta and its competitors are selling auth as a service: doing auth yourself properly is a massive pain that you need to stay on top of. You need to set up secure hashes, integrate TOTP/FIDO2 with appropriate recovery mechanisms, set up login flows, deal with session expiration, and all that stuff, when all you want is "give me a user ID so I know what data to load". These systems are annoying to develop against (though plenty of libraries are available to do the hard parts for you) but they're great if you just want to secure a backend or web application. I don't know why you needed two extra assertions when you were already authenticated, though. That's sounds like bad integration to me.
- foxyv 3y ago
  Signing into AWS API through OKTA using a SAML Identity Provider. Just the way it was implemented unfortunately. OKTA's API is okay for this sort of stuff, but they need a SAML Assertion API that doesn't require scraping HTML. Also it would be nice if their JSON formatting weren't so all over the place. So it went: OKTA Assertion -> OKTA SAML Assertion -> AWS STS Token > That's sounds like bad integration to me. No arguments here.

by foxyv 3y ago

jeroenhd 3y ago

Not having to deal with auth yourself makes your life so much easier. For my self hosted stuff, I've out a simple OIDC requirement in my Apache config (https://github.com/OpenIDC/mod_auth_openidc https://github.com/OpenIDC/mod_auth_openidc) and have set up a plain Keycloak server (should've gone with something simpler but oh well). Apache now sets the user ID in a header (that doesn't get passed on from the client for obvious security reasons) and all the application on the other end needs to do is look up the user ID. Multi factor authentication, password recovery, session expiration and everything else is all handled by Keycloak and no unauthenticated requests can make it through Apache. Tokens are signed and verified, of course, so there's no faking anything. I think Caddy has a similar system built in, including a login page and everything. Give or six lines of config are all you need to handle authentication, plus you get automatic security updates for your authentication flow in case something happens. There's a reason Okta and its competitors are selling auth as a service: doing auth yourself properly is a massive pain that you need to stay on top of. You need to set up secure hashes, integrate TOTP/FIDO2 with appropriate recovery mechanisms, set up login flows, deal with session expiration, and all that stuff, when all you want is "give me a user ID so I know what data to load". These systems are annoying to develop against (though plenty of libraries are available to do the hard parts for you) but they're great if you just want to secure a backend or web application. I don't know why you needed two extra assertions when you were already authenticated, though. That's sounds like bad integration to me.

foxyv 3y ago
Signing into AWS API through OKTA using a SAML Identity Provider. Just the way it was implemented unfortunately. OKTA's API is okay for this sort of stuff, but they need a SAML Assertion API that doesn't require scraping HTML. Also it would be nice if their JSON formatting weren't so all over the place. So it went: OKTA Assertion -> OKTA SAML Assertion -> AWS STS Token > That's sounds like bad integration to me. No arguments here.