Regístrese ahora para una mejor cotización personalizada!
Building applications to automate management of your Webex organization is easy -keeping admin user OAuth access tokens refreshed is harder. HashiCorp Vault can help!
While Webex -with all its collaborationandproductivity enhancement features -is a powerful and delightful platform in-and-of itself, two key value propositions stand out for enterprise developers: meticulous focus on security, and expansive API capabilities. The promise of making IT's life easier by automating administrative Webex tasks using scripts and applications is where security and APIs truly meet...
To make sure applications are authorized to perform particular operations, Webex APIs require that aBeareraccess token be presented as part of each API request, for example:
GET /v1/people/me HTTP/1.1Authorization: BearerZGU5MDc2NjctZredacted17f-9974-ad72cae0e10fHost: webexapis.com
The process for obtaining an API access token varies a bit depending on which of two main credential types the app operates under: as a Bot, or as an Integration (the less commonly used Guest Issuer credential is also available, but wouldn't typically be used for admin apps.)
Some of the key differences between Bots and Integrations include:
Bots:Statically configured 'Machine' accounts that can perform API operations acting as their own unique bot user.
Integrations:Implement OAuth2 authentication flows to obtain credentials for acting on end-users' behalf.
Glancing at the above, you might be tempted to select a Bot application type for an an admin app since the access token is statically generated and lasts indefinitely; however, note that Bots can not perform admin operations!
The correct choice is to use an Integration application type, since an access token generated via OAuth2 can be used to perform any operation the authenticating user is allowed to perform. One of the challenges in building Integration apps is implementing the OAuth2 flow, which requres a real, live human to authenticate via a web browser. The other challenge is that OAuth2 generated tokens last only 14 days:
Imagine you are tasked with building an application that compiles a monthly report of Webex meeting activity using the Webex REST API /v1/analytics/meetingsMetrics/aggregates resource. You've been able to successfully implement an OAuth2 grant flow allowing an admin user to login and generate an access token, then use the token to retrieve the data. However, if the application stores this access token and attempts to use it a month later, the access token will have expired, requiring the admin to manually authorize the app again.
This is where Vault (plus Puppet Labs' vault-plugin-secrets-oauthapp) comes into the picture!
Any Webex application -whether Bot, Integration, or Guest Issuer -has a key responsibility to protect access tokens and other secrets that could be used by potential attackers to invade privacy, steal/destroy data, or disrupt communications. Using a centralized, ultra-secure secret management solution like Vault is a great best-practice for keeping enterprise secrets organized, controlled, and safe. We'll also see how Vault can transparently generate and auto-refresh Webex OAuth2 access tokens, making the access token generation/refresh process automatic and highly secure.
Vault can be used to statically store all kinds of secrets, but the OAuth2 access token generation and auto-refresh functionality we're looking for doesn't come with Vault out of the box -for that we will be using a Vault plugin developed by Puppet Labs: vault-plugin-secrets-oauthapp.
Note:This tutorial was created using the following software versions installed. Please see the respective projects' web sites for installation details:
Caveat:For simplicity, the tutorial below demonstrates Vault config/access via the official Vault container, in development mode. For production, you will absolutely not want to use this Vault implementation, but rather a fully hardened and professionally managed Vault instance.
tar -xvf vault-plugin-secrets-oauthapp-v3.0.0-linux-amd64.tar.xz
mv vault-plugin-secrets-oauthapp* oauthapp
docker pull vault
English
Pусский
Français
Español
Português
docker run -it \--name vault \-p 8200:8200 \-v${PWD}/oauthapp:/etc/vault/plugins/oauthapp \vault:latest server -dev -dev-plugin-dir /etc/vault/plugins A brief explanation of the parameters:
| Parameter | Value |
| -it | Run the container in an interactive terminal |
| -name vault | Name the container 'vault' for ease of access later |
| -p 8200:8200 | Expose the Vault API port for client application access |
| -v${PWD}/oauthapp:/etc/vault/plugins/oauthapp | Mounts the oauthapp plugin binary (from the current working directory) into the container |
| server | Start the Vault server |
| -dev | Start Vault in development mode |
| -dev-plugin-dir /etc/vault/plugins/ | Location for Vault plugins |
You should see output similar to the below:
Note the generated Root Token shown at the bottom of the log output, e.g:
This will be the Vault access token we'll use when performing Vault client and API operations -copy it to a safe place.
Note also that the oauthapp plugin was successfully registered.
Caveat:While we'll use this root Vault token in the steps below, in production you will absolutely want to use a proper, generated identity token unique to your application.
docker exec -it vault sh
export VAULT_ADDR='http://0.0.0.0:8200'
vault login <vault_token>
vault secrets enable oauthapp
At this point we are ready to create an oauthappserverthat will manage Webex OAuth2 credentials for our application; however, before we can do that we need to register a new Webex Integration:
vault write oauthapp/servers/webex-myapp provider=customclient_id=<client_id> client_secret=<client_secret>provider_options=auth_code_url="https://webexapis.com/v1/authorize"provider_options=token_url="https://webexapis.com/v1/access_token"
A brief explanation of the parameters:
| Parameter | Value |
| write | We're storing information in Vault |
| oauthapp/servers/webex-myapp | We're defining a new oauthapp server (equiv. to a specific Webex Integration), named webex-myapp |
| client_id | Copied from the Integration page |
| client_secret | Copied from the Integration creation page |
| provider=custom | Webex is not one oauthapp's built-in providers -we'll need to create a custom provider here |
| provider_options=auth_code_url | This is the URL where the Webex OAuth2 authorization code grant flow should initate |
| provider_options=token_url | This is the URL where authorization codes can be exchanged for access tokens |
You should see output similar to:
Now that the Vault server is fully configured, let's see how to use Vault/oauthapp to perform the Webex OAuth2 authorization code grant flow 'manually' via the Vault CLI:
vault write oauthapp/auth-code-url server=webex-myapp redirect_url="http://localhost:5000" scopes="spark:people_read" state="12345"
A brief explanation of the parameters:
| Parameter | Value |
| write | Since the state parameter (which should be unique for each OAuth2 attempt) needs to be persisted across commands, this is a Vault write operation |
| oauthapp/auth-code-url | We're creating a new auth-code-url definition |
| server=webex-myapp | We want to authenticate using the 'webex-myapp' server associated with our specific Webex Integration |
| redirect_url="http://localhost:5000
Anterior:Finding My Home at Cisco
|
Etiquetas calientes:
