3 ms·

Where do they say that?

adeinega 2y ago
https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html https://docs.aws.amazon.com/cognito/latest/developerguide/ex... tells me they support these IDPs 1. Facebook 2. Login with Amazon 3. Google 4. Sign in with Apple 5. Open ID Connect providers, and finally 6. SAML identity providers If we look a bit closer, we notice that the first four use OpenID Connect under the hood. These names are fancy names for OpenID Connect with a little bit of something extra on top from Apple, Google, and so forth.
- p_l 2y ago
  AWS SSO, ASS Cognito, and SSO (SAML/OIDC) integration in AWS IAM/STS are all three different things, with separate behaviours, problems, typical Amazon undocumented pitfalls, etc.
p_l 2y ago
They say this in how you simply are limited in what you can pass and control when using OIDC Vs SAML. SSO -> token that works only for specific role, where the specific user is supposed to be able to take many roles, is very hard to do with OIDC unless you can mangle OIDC tokens properly, whereas it's way simpler to do with SAML
- adeinega 2y ago
  I'd love to read about that more if you can share links explaining those details. Whatever you've described sounds more like internal problems / challenges of their own implementations than anything else... especially the OpenID Connect as a delegated authentication protocol itself.
  - p_l 2y ago
    It's been over 2 years since I dealt with it, but in essence the details boiled down to much bigger size limits for SAML assertions vs. how big a JWT token could be passed to AWS STS for AssumeRole call. 100000 characters of base64 vs few kilobytes of JWT, an error we hit very very early. Also, for practical purposes, you can parse available roles out of SAML2 response from IdP, presenting a menu to the user asking them to select the right role. To deal with OIDC having way smaller space for "assertions", I ended up adding extra parameters to OIDC login request, and modified our IdP (keycloak) to parse it and filter user's groups (set from AD) to only include the group passed in parameter. This way we could always "fit" inside OIDC token limits in STS. This was in regulated environment where users had to be given very fine grained access, and simultaneously could have many, many, many roles available - and had to be able to switch between them at runtime. I think we blew the STS the moment we fed the IdP with real group membership dataset instead of the less than 10 groups we had used in tests. Don't recall if it also didn't trigger some really hilarious errors that I recall seeing, like Sagemaker exploding with EC2 ENI attachment errors, but that one could have been triggered by something else.

https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html https://docs.aws.amazon.com/cognito/latest/developerguide/ex... tells me they support these IDPs 1. Facebook 2. Login with Amazon 3. Google 4. Sign in with Apple 5. Open ID Connect providers, and finally 6. SAML identity providers If we look a bit closer, we notice that the first four use OpenID Connect under the hood. These names are fancy names for OpenID Connect with a little bit of something extra on top from Apple, Google, and so forth.

p_l 2y ago
AWS SSO, ASS Cognito, and SSO (SAML/OIDC) integration in AWS IAM/STS are all three different things, with separate behaviours, problems, typical Amazon undocumented pitfalls, etc.

p_l 2y ago

They say this in how you simply are limited in what you can pass and control when using OIDC Vs SAML. SSO -> token that works only for specific role, where the specific user is supposed to be able to take many roles, is very hard to do with OIDC unless you can mangle OIDC tokens properly, whereas it's way simpler to do with SAML

adeinega 2y ago
I'd love to read about that more if you can share links explaining those details. Whatever you've described sounds more like internal problems / challenges of their own implementations than anything else... especially the OpenID Connect as a delegated authentication protocol itself.
- p_l 2y ago
  It's been over 2 years since I dealt with it, but in essence the details boiled down to much bigger size limits for SAML assertions vs. how big a JWT token could be passed to AWS STS for AssumeRole call. 100000 characters of base64 vs few kilobytes of JWT, an error we hit very very early. Also, for practical purposes, you can parse available roles out of SAML2 response from IdP, presenting a menu to the user asking them to select the right role. To deal with OIDC having way smaller space for "assertions", I ended up adding extra parameters to OIDC login request, and modified our IdP (keycloak) to parse it and filter user's groups (set from AD) to only include the group passed in parameter. This way we could always "fit" inside OIDC token limits in STS. This was in regulated environment where users had to be given very fine grained access, and simultaneously could have many, many, many roles available - and had to be able to switch between them at runtime. I think we blew the STS the moment we fed the IdP with real group membership dataset instead of the less than 10 groups we had used in tests. Don't recall if it also didn't trigger some really hilarious errors that I recall seeing, like Sagemaker exploding with EC2 ENI attachment errors, but that one could have been triggered by something else.