alexvanin/certificates
1
0
Fork 0
forked from TrueCloudLab/certificates
Code Pull requests Activity

A few fixes to the OIDC provisioner docs

Browse source
This commit is contained in:
max furman 2019-03-26 14:43:06 -07:00
parent 52f09605f4
commit f75a52d55b
1 changed files with 25 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
docs/GETTING_STARTED.md
View file

@ -418,7 +418,7 @@ Please enter a password to encrypt the provisioner private key? password
},
[...]
# launch CA...
## launch CA...
$ step-ca $(step path)/config/ca.json
Please enter the password to decrypt ~/.step/secrets/intermediate_ca_key: password
2019/02/21 12:09:51 Serving HTTPS on :9443 ...
@ -453,22 +453,23 @@ $ step ca renew site.crt site.key
error renewing certificate: Unauthorized
```
## Leverage G-Suite's OAuth OIDC as authenticate personal certificates for users
## Use Oauth OIDC to obtain personal certificates
To authenticate users with the CA you can leverage services that expose OAuth OpenID
Connect identity providers. One of the most common provider and the one we'll use in
this example is G-Suite.
To authenticate users with the CA you can leverage services that expose OAuth
OpenID Connect identity providers. One of the most common providers, and the
one we'll use in this example, is G-Suite.
Navigate to the Google APIs developer console and pick a suitable project from the
top navbar's dropdown.
![Google Dev Console](oidc1.png)
In the masthead navigation click **Credentials** (key symbol) and then "OAuth consent
screen" from the subnav. Fill out naming details, all mandatory fields, and decide if
your app is of type **Public** or **Internal**. Internal will make sure the access scope
is bound to your G-Suite organization. **Public** will let anybody with a Google Account
log in, incl. `gmail.com` accounts.
In the masthead navigation click **Credentials** (key symbol) and then "OAuth
consent screen" from the subnav. Fill out naming details, all mandatory fields,
and decide if your app is of type **Public** or **Internal**. Internal
will make sure the access scope is bound to your G-Suite organization.
**Public** will let anybody with a Google Account log in, incl.
`gmail.com` accounts.
Move back to **Credentials** on the subnav and choose "OAuth client ID" from the
**Create credentials** dropdown. Since OIDC will be used from the `step CLI` pick **Other**
@ -476,15 +477,18 @@ from the available options and pick a name (e.g. **Step CLI**).
![Create credential](oidc2.png)
On successful completion, a confirmation modal with both `clientID` and `clientSecret` will
be presented. Please note that the `clientSecret` will allow applications access to the configured
OAuth consent screen. However, it will not allow direct authentication of users without their own
MfA credentials per account.
On successful completion, a confirmation modal with both `clientID` and
`clientSecret` will be presented. Please note that the `clientSecret` will
allow applications access to the configured OAuth consent screen. However, it
will not allow direct authentication of users without their own MfA credentials
per account.
![OIDC credentials](oidc3.png)
Now using `clientID` and `clientSecret` run following command to add G-Suite as a provisioner to
`step certificates`. Please see [`step ca provisioner add`](https://smallstep.com/docs/cli/ca/provisioner/add/)'s docs for all available configuration options and descriptions.
Now using `clientID` and `clientSecret` run the following command to add
G-Suite as a provisioner to `step certificates`. Please see [`step ca
provisioner add`](https://smallstep.com/docs/cli/ca/provisioner/add/)'s docs
for all available configuration options and descriptions.
```bash
$ step ca provisioner add Google --type oidc --ca-config $(step path)/config/ca.json \
@ -494,8 +498,9 @@ $ step ca provisioner add Google --type oidc --ca-config $(step path)/config/ca.
--domain yourdomain.com --domain gmail.com
```
Start up the online CA or send a HUP signal if it's already running to pick up the new provisioner.
Now users should be able to fetch certificates using the familiar `step ca certificate` flow:
Start up the online CA or send a HUP signal if it's already running to reload
the configuration and pick up the new provisioner. Now users should be able to
obtain certificates using the familiar `step ca certificate` flow:
```bash
$ step ca certificate sebastian@smallstep.com personal.crt personal.key
@ -517,7 +522,8 @@ X.509v3 TLS Certificate (ECDSA P-256) [Serial: 2295...5799]
to: 2019-03-27T19:02:58Z
```
Now it's easy for anybody in the G-Suite organization to self-serve fetching valid certificates.
Now it's easy for anybody in the G-Suite organization to obtain valid personal
certificates!
## Notes on Securing the Step CA and your PKI.