Skip to end of metadata
Go to start of metadata

If you're wanting to leverage the integrated platform services from AWS  you must use them as they were intended to be used otherwise you may end up implementing OAuth/OIDC tokens in the wrong context and make your app much less secure than you had hoped.  Also, AWS services must be configured in a way that implements the protocols available at the UW IdP (SAML or OIDC).  Some options can be more of an enabler than others but also come at an increase in cost and complexity.

All of these options (SAML or OIDC) require you to register your client ahead of time with UW-IT IAM.  If you are using SAML in these options below where its available then normal SP Registry process applies, otherwise contact about alpha testing OIDC options.


AuthN as a Service - Application Load Balancer + Any Backend

If you have a simple app (Lambda, Instance Id or IP) and want simple assurance that your end user has authenticated with the UW IdP then use this option.  The ALB handles end user authentication using OIDC and then passes to your backend target an http header which includes the OIDC Id token which includes the users netid and any claims that you requested during client registration (UW Groups etc).  This can be easily integrated with R53 to enable lambdas as targets without the need for API Gateway.  With this kind of architecture you set trust within your VPC between your lambdas and the ALB.


AuthN as a Service - Cognito Identity Pools + Any Backend

The solution is less expensive than Cognito User Pools (below) and instead uses Cognito Identity Pools.  This solution permits direct calls to AWS services based on the IAM policies/roles (using STS) that you define on a per registered SAML or OIDC client basis.


  • The documentation can be found here.  Requires that you fist setup an OIDC Identity Provider.
  • If the UW IdP were to "rollover" their public cert you have to manually re-generate the UW IdP thumbprint you created in the AWS IAM Identity Provider.
  • This has not yet been tested or known to work with the UW IdP (SAML or OIDC).
  • In theory, SAML should work just fine, OIDC may have the same bugs as the above ALB option.

        External Provider Enhanced Authflow

AuthN and AuthZ as a Service - Cognito User Pools + API Gateway + Lambda

If you are designing a suite of micro-services where you have various applications in front of them, each of which may be calling your micro-services with different authorization scopes then you should use Cognito User Pools with a federated SSO (OIDC or SAML).  This enables you to define your own OAuth 2.0 clients using Cognito and then have very tight integration with API Gateway and Lambda's.  


  • The documentation can be found here for the Cognito setup.  And here for the API Gateway setup.
  • This is a very complex setup.
  • This will require additional Cognito Lambda Triggers to be invoked so that you can trim the very long attributes sent from the UW IdP to get around the field storage limits (256KB) in the user pool.
  • This will double your lambda invocation count.
  • API Gateway times out after 30seconds (hard limit, regardless of 15min lambda limit) and can get expensive
  • Cognito with Federated SAML is expensive
  • This has been tested and works with the UW IdP Federated SAML.
  • This has not yet been tested with the UW IdP Federated OIDC.

                    Authentication flow diagram for using SAML IdP with a user

Custom AuthN and Custom AuthZ - Lambda with OIDC RP Library

In essence, you implement the OIDC protocol, specifically the role of the Relying Party (RP) in a Lambda.  You can route http requests to your Lambda using API Gateway or an Application Load Balancer.  When doing that they can be set to send all traffic and are really only used to give your Lambda a URL.  Optionally, you can use a Custom Lambda Authorizer to protect some of your routes with code that you write.  This code could implement the OIDC protocol or provide a light weight authorization layer by looking at claim attributes in an OIDC id token.


  • No labels