Tools to manage configuration and maintenance of federating identity between Google Apps (as the identity provider) and AWS.
- Clone this repo
- In the top-level directory, run
pip install --upgrade .
(if you want to install to just a user-specific directory, userpip install --upgrade --user .
) - That's it!
- Google Apps set up already. You're going to need to generate secrets for the federator.
- You need to know your unique Google 'customer ID'. You can get this from the Google Admin
Console, via
Security -> Set up Single Sign On (SSO)
-- the customer ID is the bit on the tail end of the Entity ID URL that looks like this:https://accounts.google.com/o/saml2?idpid=XXXXXXXXX
(the "XXXXXXXXX" part)
- You'll need to register the federator as an external app with Google Apps first:
- Log in to your Google Apps Developer Console via https://console.developers.google.com
- At the top of the page, there's a pulldown menu; by default, it's marked
Select a project
. If you click on it, you can chooseCreate a Project
, which you should do - Name the project
Federator
(you can call it something else, but you'll have to translate the rest of this documentation). You can change the App Engine location if it matters to you underAdvanced Options
but that's not required. You'll also have to agree to the T&Cs before creating the project, and choose whether to opt-in to the spam^H^H^H^Hmarketing emails. - Click
Create
to create your new project. - We will have to enable the admin APIs for this project before we create the credentials,
so in the main API Manager screen, click
Admin SDK
underGoogle Apps APIs
(you may have to click on theMore...
button underneath that heading). When the API screen appears, clickEnable
. - Authentication and authorization for Federator will be via the OAuth2
Installed Apps
pattern, so we will need to create some client identifiers. At the left-hand-side of the screen,
click
Credentials
and then when the popup appears, chooseCreate credential
and, from the pulldown menu, chooseOAuth2 Client ID
. From the selection of client types, chooseOther
, and set the client name to beFederator CLI
. ClickCreate
- There'll be a popup which displays your OAuth2 Client ID and the client secret. Store these safely, as they will be used to identify your Federator CLI to Google.
- You will need to set up a SAML Identity Provider within your AWS account, and IAM roles which
trust that Identity Provider. You can find an excellent tutorial on doing that at
Amazon's Security Blog. Note that the blog post tells you how to
do everything, including setting up the Google schema; when you get to
Step 4: Add the AWS SAML attributes to your Google Apps user profile
, you can use the Federator to create the custom Schema (see below for usage). - Step 5 in that document will have to be carried out manually for the moment -- I don't have code to create the SAML App in Google yet.
- Step 6 in that guide can be done using the Federator -- see below for usage on adding/removing user roles.
In order to grant access to the Federator to modify your Google Apps Domain Users, you'll need to authenticate, via the OAuth2 browser flow, as a user who has the appropriate access. The Federator will need to have access to modify custom user schemas (to create the schema for the federated roles) and to modify users (to assign those roles from within the new custom schema to users).
locahost$ federator init -I <client_id> -C <client_secret>
The script will cause a browser to be opened, where you can sign in as an appropriate user and
approve the access. Once this has been done once, the credentials will be stored in a file
under $HOME/.federator
-- these credentials expire after one hour after they become idle,
but they include a refresh token and will be transparently re-issued on demand, provided your
Google Apps Domain User is still valid.
Credential files are specific to the scope of access that they need.
Once the persistent credentials file(s) have been created, you will not have to go through the browser auth steps again while the credentials are valid.
You can use Federator to add the required custom schema to your Google Apps Domain. This custom schema is required to define the "shape" of the data that will be used when passing SAML assertions from Google (as an Identity Provider, or IdP) to Amazon (as the Service Provider, or SP).
TL;DR: Federator can make your Google Apps Domain the right shape to use AWS via Google Auth.
localhost$ federator schema -C <customerid> create
If the custom schema has already been created, nothing will be done. If the custom schema has
been created, but is the wrong "shape", then nothing will still be done. If you want to update
the custom schema, you will have to delete the existing one, and create a new one (see below for
delete
functionality)
Federator can "clean up" by removing the custom AWS SSO schema. Simply:
localhost$ federator schema -C <customerid> delete
If the custom schema has already been deleted, nothing will happen.
It also seems like the schema cannot be deleted if it's in use -- in other words, if any users have attributes that are described by the custom schema.
Federator can verify that the custom schema has been created:
localhost$ federator schema -C <customerid> verify
Schema exists
Federator will also return exit code 0 if the schema exists, and exit code 1 if it doesn't.
You can dump out the schema quite simply:
localhost$ federator schema -C <customerid> show
{
"etag": "\"XAsypnOPUm9mxokHB31cC07VbXs/hDT2ACjbO2nrT_uVUpNU3VQ_QzU\"",
"fields": [
{
"etag": "\"XRsypGOPUmlmxokHB51cC07Vb3s/mF8fcTzvlteJZ0DIlUljKGlhlfw\"",
"fieldId": "CfnqfA4pRxqP8i8ueR1wew==",
"fieldName": "role",
"fieldType": "STRING",
"kind": "admin#directory#schema#fieldspec",
"multiValued": true,
"readAccessType": "ADMINS_AND_SELF"
}
],
"kind": "admin#directory#schema",
"schemaId": "JfLx5all7--VnMs-H39aNQ==",
"schemaName": "SSO"
}