All Projects → cevoaustralia → google-aws-federator

cevoaustralia / google-aws-federator

Licence: MIT license
A small command line tool to help manage AWS Federated Identities authenticated through Google Apps

Programming Languages

python
139335 projects - #7 most used programming language
Makefile
30231 projects

Projects that are alternatives of or similar to google-aws-federator

Aws Google Auth
Provides AWS STS credentials based on Google Apps SAML SSO auth (what a jumble!)
Stars: ✭ 428 (+1375.86%)
Mutual labels:  saml, amazon
amazon-ecs
With Laravel, search and lookup Amazon products easily.
Stars: ✭ 52 (+79.31%)
Mutual labels:  amazon
Lite Idp
Lightweight SAML Identity Provider
Stars: ✭ 130 (+348.28%)
Mutual labels:  saml
Arkid
一账通是一款开源的统一身份认证授权管理解决方案,支持多种标准协议(LDAP, OAuth2, SAML, OpenID),细粒度权限控制,完整的WEB管理功能,钉钉、企业微信集成等
Stars: ✭ 217 (+648.28%)
Mutual labels:  saml
Gsts
Obtain and store AWS STS credentials to interact with Amazon services by authenticating via G Suite SAML.
Stars: ✭ 136 (+368.97%)
Mutual labels:  saml
Spring Security Pac4j
pac4j security library for Spring Security: OAuth, CAS, SAML, OpenID Connect, LDAP, JWT...
Stars: ✭ 231 (+696.55%)
Mutual labels:  saml
Awsaml
Awsaml is an application for providing automatically rotated temporary AWS credentials.
Stars: ✭ 120 (+313.79%)
Mutual labels:  saml
node-red-contrib-sonospollytts
Play speech TTS using Sonos.
Stars: ✭ 11 (-62.07%)
Mutual labels:  amazon
undertow-pac4j
Security library for Undertow: OAuth, CAS, SAML, OpenID Connect, LDAP, JWT...
Stars: ✭ 35 (+20.69%)
Mutual labels:  saml
Saml idp
Ruby SAML Identity Provider, best used with Rails (though not required)
Stars: ✭ 184 (+534.48%)
Mutual labels:  saml
Aspnetsaml
Very simple SAML 2.0 consumer module for ASP.NET/C#
Stars: ✭ 177 (+510.34%)
Mutual labels:  saml
Globalprotect Openconnect
A GlobalProtect VPN client (GUI) for Linux based on OpenConnect and built with Qt5, supports SAML auth mode.
Stars: ✭ 143 (+393.1%)
Mutual labels:  saml
Authing
🔥Authing - IDaaS/IAM solution that can Auth to web and mobile applications.
Stars: ✭ 247 (+751.72%)
Mutual labels:  saml
Mumuki Laboratory
🔬 Where students practice and receive automated and human feedback
Stars: ✭ 131 (+351.72%)
Mutual labels:  saml
privacy-settings
Guide to privacy settings for most major softwares and services.
Stars: ✭ 97 (+234.48%)
Mutual labels:  amazon
Cipheridaas
CipherIDaaS —— Open-source IDaaS/IAM product by CipherChina , Hangzhou .
Stars: ✭ 121 (+317.24%)
Mutual labels:  saml
Pac4j
Security engine for Java (authentication, authorization, multi frameworks): OAuth, CAS, SAML, OpenID Connect, LDAP, JWT...
Stars: ✭ 2,097 (+7131.03%)
Mutual labels:  saml
Saml2
SimpleSAMLphp low-level SAML2 PHP library
Stars: ✭ 229 (+689.66%)
Mutual labels:  saml
scripts
Scripts for managing my Ubuntu / Rclone / Plex Server
Stars: ✭ 20 (-31.03%)
Mutual labels:  amazon
wp-saml-auth
Rock-solid SAML authentication for WordPress built on a modern foundation.
Stars: ✭ 75 (+158.62%)
Mutual labels:  saml

Google AWS Federator

Tools to manage configuration and maintenance of federating identity between Google Apps (as the identity provider) and AWS.

Installation

  1. Clone this repo
  2. In the top-level directory, run pip install --upgrade . (if you want to install to just a user-specific directory, user pip install --upgrade --user .)
  3. That's it!

Setup

Prerequisites

  1. Google Apps set up already. You're going to need to generate secrets for the federator.
  2. 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)

Configuration

  1. You'll need to register the federator as an external app with Google Apps first:
    1. Log in to your Google Apps Developer Console via https://console.developers.google.com
    2. 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 choose Create a Project, which you should do
    3. 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 under Advanced 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.
    4. Click Create to create your new project.
    5. 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 under Google Apps APIs (you may have to click on the More... button underneath that heading). When the API screen appears, click Enable.
    6. 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, choose Create credential and, from the pulldown menu, choose OAuth2 Client ID. From the selection of client types, choose Other, and set the client name to be Federator CLI. Click Create
    7. 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.
  2. 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).
  3. 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.
  4. Step 6 in that guide can be done using the Federator -- see below for usage on adding/removing user roles.

First Run

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.

Subsequent Runs

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.

Usage

Creating AWS SSO Schema

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)

Deleting the AWS SSO Schema

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.

Validating whether the custom AWS SSO Schema has been created

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.

Examining the created custom AWS SSO Schema

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"
}
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].