Design and build out of band authentication and authorization provider

[gene1wood]

Second Opinion Model of Authentication and Authorization

Build the OIDC provider, wire it into the Duo API and create a test authorization datastore.

[gdestuynder]

related https://github.com/mozilla-iam/auth0-scripts/issues/3

[gene1wood]

So far the Duo components have been completed and tested. I initially attempted to use chalice but encountered a bunch of bugs and I lost confidence in it. I moved to using Zappa which doesn't attempt to map Flask routes to API Gateway endpoints but instead just tells API Gateway to forward all traffic to the lambda function. This approach has been working.

I've been working on the OIDC interface which has been challenging. The main OIDC library for python is pyoidc. I've attempted to get the simple_op example code in the project working under cherrypy but encountered a number of challenges. I've moved to a plan where I'm building a Flask extension and adding each OIDC endpoint individually in a Flask idiom, building from scratch instead of extending the existing simple_op code.

So far this is working but if I encounter any significant issues I will likely switch to implementing the OIDC interface without the pyoidc library.

I'm hoping to finish the Flask extension by early next week.

https://github.com/gene1wood/second-opinion

[gene1wood]

I've gotten the server side working for both the OIDC interface and the Duo backend! I'm now working on the Lua code for the nginx client side which will act as a reference architecture for RPs that want to use this system. This Lua code needs to authenticate to Auth0, get back authentication and authorization data, then pass the authentication data (the user's email) on to a second OIDC call to second-opinion which will return a new set of authentication and authorization data from the out of band system and Duo. Then the Lua code compares the two to make sure they match and if they do, and if the user is a member of the right groups, allows them to continue through the reverse proxy.

[gene1wood]

I completed a first successful end to end test last week with the new Nginx Lua client code. This includes

• user browses to Nginx Lua reverse proxy RP
• RP redirects the user to auth0
• user authenticates to auth0 and duo and is sent back to the RP
• RP redirects the user to second-opinion (in this test running on my laptop)
• second-opinion gives the user a Duo login prompt and the user authenticates and is sent back to the RP
• RP gets the user along with now two assertions about their identity and http headers for both OPs along with the intersection of the group membership of both OPs

Client support was added to testrp in mozilla-iam/testrp.security.allizom.org#17 and deployed to the live site last week. This PR also added group based access control to testrp allowing an RP to enumerate the groups in the reverse proxy that they want to grant access to so their backend web app need not have any authorization functionality at all.

I've also gotten the server side components deployed to AWS and working (at least to the discovery endpoint).

I'm currently working on

• cleaning up the code
• deploying to production

Once that's done I'll begin adding in the group data fetching, caching and signature verification code.

[gene1wood]

This sprint I've been focusing on the deployment layout and developing the signature verification code. This was a change in order from what I'd planned (planned to deploy first, then implement signature verification).

The signing model now involves a GPG signing root authority which is a single dedicated GPG keypair, for which the fingerprint is hard coded into the second-opinion code.

This root authority key is then used to sign a "key signing map" file that lives out in an s3 bucket (see the deployment diagram below). This key signing map indicates what files can be signed by what signers.

The final and third tier of this signing chain is the actual files containing either second-opinion config code or an RP or teams group authorization data. These files are signed by gpg signers who are listed in the key signing map.

This code is completed and I'm now continuing working on deployment based off of the plan below.

I'm going to generalize the CloudTrail Secure Storage AWS account into a dedicated sequestered account (that nobody has regular login rights to and that requires pulling an MFA token from a safe)

The next tasks are

• to finish this deployment layout
• create credstash infrastructure in the sequested AWS account
• rename the sequestered AWS account
• identify a DNS name that can either live in route53 in the sequestered account or in a physical datacenter (the concern would be that a route53 record in infosec-prod could be pointed elsewhere in the event of an infosec-prod compromise
• create that route53 zone in the sequestered account
• deploy dev second-opinion to infosec-dev
• create testrp rp pointing to dev second-opinion and test
• deploy prod second-opinion to sequestered account
• test testrp against prod

[gene1wood]

• Mozilla CloudTrail AWS account has been converted to infosec-isolated acount
• Credstash infrastructure deployed in infosec-isolated
• Posing the DNS question to infra
  • Planned path forward is to select a TLD, request registration with markmonitor and set NS servers as the route53 zone in infosec-isolated

[gene1wood]

• mozilla.services (and mozilla-auth.services) have been registered, DNS zones have been created and they're now hosted in the infosec-isolated account
• additional documentation on the signing hierarchy has been completed
• currently testing some changes to the signing hierarchy before deploying

[gdestuynder]

@gene1wood this task is done right? (if yes close, since this is design/build out which i believe is done)