Amazon Web Services (AWS) and Open ID Connect (OIDC)

Session Topic: Amazon Web Services (AWS) and Open ID Connect, Q & A w/ Demo

Tuesday 2F

Notes-taker: Matt Berry

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Question: How does AWS discover IDPs?

Answer: The user enters the Issuer URL and we use the Open ID Connect Discovery Profile (without the WebFinger component, as the end user has given us the Issuer URL).

Question: How does AWS translate from an OIDC Principal to and AWS permission set?

Answer: Let’s do a quick recap of AWS Authentication and Authorization before we answer this.

Recap: AWS vends long-term Access Key and Secret Keys to users in the AWS system (IAM Users). These long term credentials are used to authenticate requests, and permission sets are attached to the IAM Users. It is not wise to use these credentials in deployed applications however, as the application can be reverse engineered to extract the credentials. Instead, use short-term Session credentials that expire after 1 hour. IAM Roles are used as the principal for these sessions. The identities for the sessions themselves are ephemeral, but they link back to the permission set of the IAM Role. The IAM Role dictates who can ‘assume’ the role, i.e. obtain a set of session credentials. So in the case of SAML or OIDC, the IAM Role ‘trusts’ an OIDC provider. Using STS.AssumeRoleWithWebIdentity, an ID Token can be exchanged for a set of Session credentials for an IAM Role. Answer (post recap): AWS translates OIDC Principals into IAM Roles, and uses the permissions associated with the Rol

Question: Can the OIDC Identity Provider pass attributes/claims through to AWS’ Authorization language?

Answer: We pump select attributes/claims through for both SAML and OIDC, however the list is much shorter for OIDC as there is no commonly accepted list of standard claims. We have considered making our implementation extensible to support custom attributes/claims and we are still researching cost/benefit tradeoff.

Question: How temporary are temporary credentials?

Answer: minimum of 15 minutes, maximum of 1 hour. Before the hour is up, an application can request new credentials, but a new ID Token is required for security purposes. This should be mostly transparent to end-users because the IDP will maintain a session for the user.

Question: How does AWS handle multi-tenant IDPs?

Answer: Depends on the flavor of multi-tenancy. Salesforce, for example, has a single identity pool and different users can log in to different salesforce applications. In this case, your IAM Role will need to check the client ID of the application to effectively limit the pool of users down to those valid for a particular salesforce application. For multi-tenant IDPs where each tenant gets its own issuer string, there are no special considerations, as AWS sees them as different IDPs.