SAML IDP delegation to Okta developer account

mogul commented 8 years ago

In order to provide a vantage point for pen-testing of UAA's SAML implementation and explore options for integrating MFA with local accounts, we want login.cloud.gov to authenticate a subset of cloud.gov users with an Okta developer IdP.

Acceptance Criteria

[ ] We can demonstrate authentication into cloud.gov for accounts specified in Okta.
[ ] We have the ability to issue new accounts in Okta for pen-testing purposes, etc.
[ ] We understand what's needed to promote existing UAA accounts to Okta-authenticated accounts

Implementation notes:

This is a well-paved path... See the UAA doc on doing this.

cnelson commented 8 years ago

I now have this working in my bosh-lite environment, those linked docs are a bit out of date.

Now looking into what's required for:

"We understand what's needed to promote existing UAA accounts to Okta-authenticated accounts"

mogul commented 8 years ago

I now have this working in my bosh-lite environment, those linked docs are a bit out of date.

Feel free to file issues or pull-requests upstream! You can do that with impunity while working for 18F. :)

"We understand what's needed to promote existing UAA accounts to Okta-authenticated accounts"

Right now, with no SAML integrations done, there are a ton of accounts in UAA for various domains, and UAA is authenticating them itself. We can specify IdPs for assorted domains if an appropriate IdP exists, and since the e-mail address matches it's pretty easy to correlate the upstream IdP's account to the existing local account, and just have it start handling authn. But we need to ensure MFA is in place for all cloud.gov accounts, and there are still going to be domains for which there is no appropriate IdP. UAA doesn't handle MFA itself, and we have no desire to hack that in; it's the wrong place for it.

So the question is, if we were to use Okta as the "fall-back" IdP, what is the technical effort and UX impact to (1) "promote" an existing UAA account to MFA by provisioning it in Okta, (2) set up new accounts there by default. Based on what we learn here we should be able to write other stories, either about doing that work with Okta or adopting a different IdP to provide MFA (eg Shibboleth). Make sense?

cnelson commented 8 years ago

We understand what's needed to promote existing UAA accounts to Okta-authenticated accounts

Promoting an existing UAA account to an Okta-authed (or any SAML IDP, referred to as "IDP" from here out) account requires the following:

Add the user to the IDP with the same email address they use to login via UAA.
Update the 'origin' column in the UAA database to match the name of the IDP (as defined in the manifest)

Note: Once the user has had their 'origin' updated in the UAA database to point to an external IDP, they can no longer login with their password, they must authenticate with the IDP. However, their password is still persisted in the DB, and if their origin is changed back to 'uaa' they could resume logging in with their password.

As of now, there's no facility to do this automatically. My testing was done by manually adding users to Okta, and altering the DB. However, the UAA API exposes the 'origin' field so this could be done without having to alter any UAA code using the publically available APIs.

In the case of Okta as the IDP they also have a robust API, so one could build an application which could promote users by:

Reading the user details via the UAA API
Creating a user in Okta with the same details via their API
Updating the users' origin to be Okta with via the UAA API

cnelson commented 8 years ago

Here's a sequence diagram describing how the process to migrate existing users would work:

Adding a net-new user is mostly the same, the only difference being they are added to Okta directly, instead of copied from UAA:

There are a couple of caveats:

To-Be-Written Glue Code

We'll either need to write some code, or manually handle the user migration from UAA to Okta. I don't think it'll be very complicated (I could spin up a working prototype in 1-2 days) but it still is a process that needs to happen for any of this to work.

Email Contents

While Okta will let us fully customize the contents of the welcome email, we can only have one configured at a time. This means if we want to migrate existing users and also be adding new users we either need to make the content of the welcome email generic enough that it works for both classes of user or migrate all existing users then swap the template out for something appropriate for new users.

Inviting new users

If we move all our users to Okta, it becomes the source of truth for users, and we'd need to write an app to handle invites, by adding the users to Okta via their API rather than the existing process which adds them to UAA.

cnelson commented 8 years ago

Here's a start to the 'TBW Glue Code'. It performs the tasks described in the sequence diagram, but does so with no error handling, and limited input validation. Consider it proof-of-concept quality code at this point:

https://github.com/cnelson/uaapp

mogul commented 8 years ago

Thanks for all the hard work and sequence diagrams... Closing this one.

Has uaapp gotten any polish? Have any sense that it my be a desirable contribution from the UAA folks?

cnelson commented 8 years ago

Has uaapp gotten any polish? Have any sense that it my be a desirable contribution from the UAA folks?

Haven't talked to CF about uaapp; Since it's a stand-alone app at best it could end up in https://github.com/cloudfoundry-community, but there's nothing to merge into UAA much like the invite app.

cnelson commented 8 years ago

Has uaapp gotten any polish? Have any sense that it my be a desirable contribution from the UAA folks?

It has gotten a bit more polish; there are tests now so I'm more confident it does what it's supposed to to do:

nosetests --with-coverage --cover-package=uaapp
.........................................................
Name                        Stmts   Miss  Cover   Missing
---------------------------------------------------------
uaapp.py                        2      0   100%   
uaapp/api.py                  143      0   100%   
uaapp/clients.py                2      0   100%   
uaapp/clients/okta.py          48      0   100%   
uaapp/clients/uaa.py           45      3    93%   175-178
uaapp/default_settings.py       9      0   100%   
uaapp/settings.py              11      0   100%   
uaapp/views.py                 24     13    46%   16-17, 22-24, 28, 32-36, 39-43
uaapp/webapp.py                46      1    98%   38
---------------------------------------------------------
TOTAL                         330     17    95%   
----------------------------------------------------------------------
Ran 57 tests in 0.218s

and I used the look/feel/css from UAA to skin the UI a little bit. It's going to take a bit of work to get this app ready to deploy via cloud foundry, but here's some screenshots of it running locally to explain how the flow works

Step 1: When you load the app, it sends you to the UAA oauth flow to get permissions to operate on your behalf

Step 2: After authorizing the app a page is presented allowing you set the options for the migration

You can select the IDP to migrate users to/from, optionally filtering users by domain, and you can enter the subject / body for a notification that will be sent to them after migration is complete:

Step 3: You are displayed a confirmation screen for the actions you selected:

Step 4: The app uses the UAA APIs to migrate the users

That's all there is to it!

cloud-gov / cg-atlas