Authorizing API Gateway against a Cognito federated identity pool

candlerb · March 12, 2018, 11:03am

I am trying to get an API Gateway/Lambda web application (python flask with serverless-wsgi) to use a Cognito federated identity pool to authenticate/authorize web clients. The underlying requirement is to get a number of apps to permit access only to authorized Salesforce or Office365 users; and I don’t want to write OpenID Connect code in each application, but want to outsource this pain to Cognito.

So I created a Salesforce identity provider in IAM, and a Cognito identity pool linked to this, following this guide. (Aside: unclear as to what the callback URL should be, but I just used my app URL with /callback appended for now)

And I added to serverless.yml:

  web:
    handler: wsgi.handler
    events:
      - http:
          path: /
          method: ANY
          authorizer:
            arn: arn:aws:cognito-identity:eu-west-1:XXXX:identitypool/eu-west-1:YYYY
      - http:
          path: "{proxy+}"
          method: ANY
          authorizer:
            arn: arn:aws:cognito-identity:eu-west-1:XXXX:identitypool/eu-west-1:YYYY

This is based on the example here for an existing Cognito User Pool, although I realise that a Cognito Identity Pool is different (nice explanation here)

Now when I do sls deploy I get this error:

Serverless: Checking Stack update progress...
...........
Serverless: Operation failed!

  Serverless Error ---------------------------------------

  An error occurred: A3e1b0cdac43LambdaPermissionApiGateway - Unable to parse HTTP response content.

If I do SLS_DEBUG="*" sls deploy then I get a slightly different error:

Serverless: Checking Stack update progress...
.........
Serverless: Operation failed!

  Serverless Error ---------------------------------------

  An error occurred: A3e1b0cdac43ApiGatewayAuthorizer - Invalid lambda function.

  Stack Trace --------------------------------------------

ServerlessError: An error occurred: A3e1b0cdac43ApiGatewayAuthorizer - Invalid lambda function.
    at provider.request.then (/usr/lib/node_modules/serverless/lib/plugins/aws/lib/monitorStack.js:112:33)
From previous event:
    at AwsDeploy.monitorStack (/usr/lib/node_modules/serverless/lib/plugins/aws/lib/monitorStack.js:26:12)
    at provider.request.then (/usr/lib/node_modules/serverless/lib/plugins/aws/lib/updateStack.js:84:30)
From previous event:
    at AwsDeploy.update (/usr/lib/node_modules/serverless/lib/plugins/aws/lib/updateStack.js:84:8)
From previous event:
    at AwsDeploy.BbPromise.bind.then (/usr/lib/node_modules/serverless/lib/plugins/aws/lib/updateStack.js:101:12)
From previous event:
    at AwsDeploy.updateStack (/usr/lib/node_modules/serverless/lib/plugins/aws/lib/updateStack.js:95:8)
From previous event:
    at AwsDeploy.BbPromise.bind.then (/usr/lib/node_modules/serverless/lib/plugins/aws/deploy/index.js:135:39)
From previous event:
    at Object.aws:deploy:deploy:updateStack [as hook] (/usr/lib/node_modules/serverless/lib/plugins/aws/deploy/index.js:131:10)
    at BbPromise.reduce (/usr/lib/node_modules/serverless/lib/classes/PluginManager.js:372:55)
From previous event:
    at PluginManager.invoke (/usr/lib/node_modules/serverless/lib/classes/PluginManager.js:372:22)
    at PluginManager.spawn (/usr/lib/node_modules/serverless/lib/classes/PluginManager.js:390:17)
    at AwsDeploy.BbPromise.bind.then (/usr/lib/node_modules/serverless/lib/plugins/aws/deploy/index.js:101:48)
From previous event:
    at Object.deploy:deploy [as hook] (/usr/lib/node_modules/serverless/lib/plugins/aws/deploy/index.js:97:10)
    at BbPromise.reduce (/usr/lib/node_modules/serverless/lib/classes/PluginManager.js:372:55)
From previous event:
    at PluginManager.invoke (/usr/lib/node_modules/serverless/lib/classes/PluginManager.js:372:22)
    at PluginManager.run (/usr/lib/node_modules/serverless/lib/classes/PluginManager.js:403:17)
    at variables.populateService.then (/usr/lib/node_modules/serverless/lib/Serverless.js:102:33)
    at runCallback (timers.js:672:20)
    at tryOnImmediate (timers.js:645:5)
    at processImmediate [as _immediateCallback] (timers.js:617:5)
From previous event:
    at Serverless.run (/usr/lib/node_modules/serverless/lib/Serverless.js:89:74)
    at serverless.init.then (/usr/lib/node_modules/serverless/bin/serverless:42:50)

If I look in .serverless/cloudformation-template-update-stack.json then it looks like it’s trying to use a custom lambda authorizer (although I really don’t grok cloudformation)

"A3e1b0cdac43ApiGatewayAuthorizer": {
  "Type": "AWS::ApiGateway::Authorizer",
  "Properties": {
    "AuthorizerResultTtlInSeconds": 300,
    "IdentitySource": "method.request.header.Authorization",
    "Name": "a3e1b0cdac43",
    "RestApiId": {
      "Ref": "ApiGatewayRestApi"
    },
    "AuthorizerUri": {
      "Fn::Join": [
        "",
        [
          "arn:aws:apigateway:",
          {
            "Ref": "AWS::Region"
          },
          ":lambda:path/2015-03-31/functions/",
          "arn:aws:cognito-identity:eu-west-1:XXXX:identitypool/eu-west-1:YYYY",
          "/invocations"
        ]
      ]
    },
    "Type": "TOKEN"
  }
},

So my problems are:

Is it even possible to use API Gateway with Cognito federated Identity Pool as an authorizer?

The API gateway documentation mentions user pools, but I can see no mention of identity pools.

However this AWS post suggests it’s possible. It looks like the OpenID token is somehow exchanged for an IAM token, in which case maybe I can use aws_iam as the authorizer.

This post shows an OpenID identity pool. The app itself still needs to have its own login and callback pages which understand OpenID exchanges. I was hoping to make it as transparent to the app itself as possible, but I can give them a special login page if required.
If it is possible, does serverless support this, and if so how do I configure it?

Thanks… Brian.

candlerb · March 12, 2018, 11:28am

Update: this page is the closest I can find; it describes an angular js app which authenticates three different resources. The /google and /cip resources are authenticated against a federated identity pool, and the /google resource is authorized only to people who authenticated via the Google identity provider within that pool.

The code for this application is published, but I’m lost in the cloudformation template.

Note: I don’t necessarily want to create the identity pool from serverless; having a single pre-existing identity pool which is shared by many apps would in fact be better.

But I will need, somehow, to create permissions such that only authenticated users can access each app. Preferably this will be further restricted for authorization, e.g. only to users in a particular group, although as long as the claims are passed through to the app I can check it there.

My head is starting to explode

candlerb · March 12, 2018, 12:23pm

Oh, and just a bit of background. Right now the way I solve this is to have a couple of EC2 instances running Apache, mod_proxy and mod_auth_openidc.

Users hit the proxy URL, and mod_auth_openidc transparently redirects them to the OpenIDC provider if necessary; only when they’ve authenticated does it proxy the request through to API Gateway. It can also enforce authorisation, e.g. specific organisation claim.

The great thing about this is that it’s completely transparent to the Lambda/Flask application. The only code needed in Lambda is to check the source IP address of the connection - to check that the request is coming from the proxy, so that people can’t bypass the authentication by hitting the API gateway URL directly.

With AWS able to attach custom domains to API gateway instances, and ACS issuing the certificates for those custom domains, I thought it would be much cleaner if I could get rid of the proxy VMs and have people connect directly to API gateway. But that means doing the full OpenID authentication/authorisation in API gateway too.

Right now it looks like the web app would need to serve a bunch of Javascript which handles the entire flow:

Direct the user to the identity provider(s) to pick up credentials (IDP-specific?)
Pass these credentials to Cognito to get an IAM token (this? and/or this?)
Include the IAM token for each subsequent web access
Deal with expired tokens

… plus configure IAM roles to perform the authorisation to specific API gateway URLs.

nachoab · March 16, 2018, 7:37am

Yes it is possible to use Federated identities. This is a simple way to do it:

User requests a token directly to the provider (i.e. Google)

User sends the token to my public APIG endpoint:

- http:
    path: auth/signin/google
    method: GET
    integration: lambda-proxy
    cors:
      origin: '*'
      allowCredentials: false

On Lambda:
- Verify the token received and extract the user details (email, name…)
- Get the user identityId
- Get user credentials with getCredentialsForIdentity
- Return credentials to the user

From now, user has to sign requests from the client using those credentials to endpoints like this:

- http:
    path: /myendpoint
    method: GET
    authorizer: aws_iam
    cors:
      origin: '*'
      allowCredentials: false
      headers:
        - Content-Type
        - Authorization
        - X-Amz-Date
        - X-Api-Key
        - X-Amz-Security-Token
        - X-Amz-User-Agent

You can also take a look at this serverless auth boilerplate

candlerb · March 16, 2018, 9:17am

Thank you. Can I just clarify a few points: my scenario is a Flask web app running in Lambda, and user has a regular web browser accessing this app, just following links in HTML.

User requests a token directly to the provider (i.e. Google)

If this takes place in the browser, presumably this means my Flask app has to return a page containing Javascript for the user to request the token - or else the Flask app returns a HTTP redirect pointing the user directly to Google.

I’m guessing that the callback URL I should use when requesting the token is the auth/signin/google service you mentioned (which I need to provide as part of my Flask app)

Verify the token

Does this mean the Flask app needs to get involved in JWT decoding and signature verification? This is similar to what I’d have to do to use OpenID Connect without Cognito.

Return credentials to the user

In a cookie? Otherwise how else will the browser retain them for the next request?

From now, user has to sign requests from the client using those credentials to endpoints like this:

This part I don’t understand. How can I make the client’s web browser send headers like X-Api-Key and X-Amz-* with every request? Does every page request have to come from Javascript XmlHttpRequest, rather than just letting the browser follow links? If so this would be a complete rewrite of the app, using a client-side framework like sammy or angular.

The way I handle it at the moment is:

Flask app runs in API Gateway (using serverless-wsgi)
I have an Apache reverse proxy running in EC2
Reverse proxy runs mod_auth_openidc
Flask app has a small wrapper that blocks all requests unless the source IP is the proxy’s public IP:

def lambda_app(environ, start_response):
    if environ["REMOTE_ADDR"] not in TRUSTED_SOURCES:
        start_response("403 Forbidden", [("Content-Type", "text/html")])
        return ["Access denied"]
    return app(environ, start_response)

The net effect is that the Flask app is unmodified - it just receives HTTP requests and returns HTML pages. If an unauthenticated / unauthorized user connects to the proxy, then mod_auth_openidc intercepts this, redirects them to Google/O365 or whatever, handles the /callback response, gives them a suitable cookie, and performs the necessary authorization. e.g.

        <Location "/admin">
                AuthType openid-connect
                Require claim organization_id:XXXXXXXX
        </Location>

I was hoping to achieve something similar with API Gateway and Cognito, but looks like I was hoping for too much.

Aside: the proxy is going to remain for some other applications anyway, because those applications require HTTPS client certificate authentication, which API Gateway definitely can’t do.

You can also take a look at this serverless auth boilerplate

Ah, thank you.

As a non-Javascript person, I’m trying to decode the source to serverless-authentication-gh-pages. As far as I can see:

It’s client-side HTML and Javascript
When the user clicks on the Google login button, it triggers a redirect to page authenticationEndpoint + '/authentication/signin/google (via window.location.href)
authenticationEndpoint is an API Gateway URL front-end to lambda, in this case it’s handler.signin from serverless-boilerplate
this in turn calls the signin code from serverless-authentication-google: this part I get lost in
by the time this is complete, the user somehow lands back at the original page. However if I start from a local checkout of index.html I end up at http://laardee.github.io/serverless-authentication-gh-pages: so either this is the Google callback URL, or the authentication lambda function knows this URL.
somehow an authorization_token ends up in local storage
when the user tries to access the protected URL (/test-token), this is done via XHR with an added Authorization: header containing this token
back in serverless-authentication-boilerplate, somehow the Authorization header is checked:

          authorizer:
            arn: replace-with-arn-of-the-authorizer-function
            resultTtlInSeconds: 0
            identitySource: method.request.header.Authorization
            identityValidationExpression: .*

(so presumably this is using a Lambda custom authorizer, not IAM authorization. In fact I don’t think it’s using Cognito at all)

But even given that I don’t understand this fully, my main take-away is that the client browser is unable to access any protected page except via XHR (to add the Authorization: header)

HintikkaKimmo · May 9, 2018, 7:45am

Run into same issue after you and your post probably saved me several hours of hitting my head to the wall… Thanks!

Topic		Replies	Views
Anyone have a good modern example of using a cognito user pool authorizer? Serverless Framework	4	3923	August 9, 2020
Cognito authorizer not being set for API gateway Serverless Framework lambda	5	2978	August 18, 2023
CognitoIdentityCredentials is not authorized to access this resource Serverless Framework lambda	2	2907	June 2, 2018
API Authentication with Cognito Serverless Framework aws	7	12823	December 18, 2018
Authorization and Authentication for API Gateway Serverless Architectures	0	636	March 25, 2019

Authorizing API Gateway against a Cognito federated identity pool

Related Topics