Usage Plans with Custom Authentication
Add custom authentication configuration to a Gloo Portal Usage Plan.
Gloo Portal Usage Plans define how users can access API Products within an Environment. If you optionally set an authPolicy
within a usage plan, Portal deterministically generates an authorization configuration that enforces the policy. To add additional authentication steps to the generated configuration, you can specify a customAuthConfig
as part of the authPolicy
.
Pre-requisites
- Install Gloo Edge Enterprise version 1.8.0 or later in a Kubernetes cluster.
- Install Gloo Portal version 1.3.0 or later in the same cluster.
- Follow the Create an API Product and Create a Portal guides to set up an Environment and Portal.
- Follow the Users and Groups Guide to create a Usage Plan with an
apiKey
Auth Policy for the Environment.
Create an AuthConfig
Define your custom authentication configuration in an AuthConfig
custom resource. For example, you can apply the following AuthConfig
derived from the “Securing the Virtual Service” step in Gloo Edge's basic auth guide, which expects user:password
as credentials.
cat << EOF | kubectl apply -f-
apiVersion: enterprise.gloo.solo.io/v1
kind: AuthConfig
metadata:
name: basic-auth
namespace: gloo-system
spec:
booleanExpr: basicAuth
configs:
- basicAuth:
apr:
users:
user:
hashedPassword: V/j4vjbW81mB6ciVZtG3g/
salt: qVKGMOtb
name: basicAuth
EOF
For more information, see the Basic Auth guide and the Gloo Edge reference documentation.
Add the AuthConfig to a UsagePlan
-
In the
basic
usage plan of thedev
environment, add theAuthConfig
in acustomAuthConfig
section.cat << EOF | kubectl apply -f- apiVersion: portal.gloo.solo.io/v1beta1 kind: Environment metadata: name: dev namespace: default spec: apiProducts: - labels: - key: app operator: Equals values: - petstore namespaces: - '*' usagePlans: - basic versions: tags: - stable displayInfo: description: This environment is meant for developers to deploy and test their APIs. displayName: Development domains: - api.example.com - api.example.com:32000 parameters: usagePlans: basic: authPolicy: apiKey: {} customAuthConfig: name: basic-auth namespace: gloo-system displayName: Basic plan with ApiKey and basic auth required rateLimit: requestsPerUnit: 3 unit: MINUTE EOF
-
Verify that the generated
AuthConfig
for thedev
environment contains the custom configuration in addition to the configuration that was generated for the API key Auth Policy.$ kubectl get -n default authconfig default-petstore-product-dev -oyaml
Example output:
apiVersion: enterprise.gloo.solo.io/v1 kind: AuthConfig metadata: ... labels: apiproducts.portal.gloo.solo.io: petstore-product.default environments.portal.gloo.solo.io: dev.default name: default-petstore-product-dev namespace: default ownerReferences: - apiVersion: portal.gloo.solo.io/v1beta1 blockOwnerDeletion: true controller: true kind: Environment name: dev ... spec: booleanExpr: (basic && (basicAuth)) configs: - apiKeyAuth: headersFromMetadata: x-solo-email: name: email x-solo-plan: name: plan required: true x-solo-username: name: username required: true labelSelector: apiproducts.portal.gloo.solo.io: petstore-product.default environments.portal.gloo.solo.io: dev.default name: apiKeys - basicAuth: apr: users: user: hashedPassword: V/j4vjbW81mB6ciVZtG3g/ salt: qVKGMOtb name: basicAuth status: statuses: gloo-system: reportedBy: gloo state: Accepted
Try it out
-
Log in to the Portal, retrieve an API key, and use the key to authorize “Try it Out” requests for “Petstore Product”. Notice that when you click “Execute”, Basic Auth credentials are now required in addition to the API key. Enter user and password.
-
Optional: You can also test the authentication by sending a curl request with and without Basic Auth credentials.
-
Send a request with API key but without Basic Auth credentials.
$ curl -v -X 'GET' \ 'http://api.example.com:32000/api/pets' \ -H 'accept: application/json' \ -H 'api-key: <API key>'
Example output, in which a
401 Unauthorized
response is returned:* Trying 127.0.0.1... * TCP_NODELAY set * Connected to api.example.com (127.0.0.1) port 32000 (#0) > GET /api/pets HTTP/1.1 > Host: api.example.com:32000 > User-Agent: curl/7.64.1 > accept: application/json > api-key: <API key> > < HTTP/1.1 401 Unauthorized < www-authenticate: Basic realm="" ... < * Connection #0 to host api.example.com left intact * Closing connection 0
-
Send a request with API key and Basic Auth credentials.
$ curl -X 'GET' \ 'http://user:password@api.example.com:32000/api/pets' \ -H 'accept: application/json' \ -H 'api-key: <API key>'
Now, the correct response is returned by
/pets
:[{"id":1,"name":"Dog","status":"available"},{"id":2,"name":"Cat","status":"pending"}]
-
Guarantees and limitations
- This feature is currently supported for Basic Auth custom configurations with ApiKey Auth Policies, and for OPA Auth custom configurations with ApiKey and OAuth Auth Policies.
- Basic Auth custom configurations are not compatible with OAuth Auth Policies.
- All other combinations of custom configuration types and Auth Policies are currently considered experimental.