Provision an AuthServer


👉 This article assumes AppSSO is installed on your TAP cluster. To install AppSSO, refer to the instructions in Install AppSSO.

👉 AppSSO is installed automatically installed with the run, iterate, and full TAP profiles, no extra steps required.

👉 To make sure AppSSO is installed on your cluster, you can run:

tanzu package installed list -A | grep "sso.apps.tanzu.vmware.com"

In this tutorial, you are going to:

  1. Set up your first authorization server, in the default namespace
  2. Ensure it is running, that users can log in

Diagram of AppSSO's components, with AuthServer and Identity Providers highlighted

Provision an AuthServer

First, deploy your first Authorization Server, along with a secret key for signing tokens.


✋ Note that we used spec.issuerURI = http://authserver.example.com, but you should customize the URL to match the domain of your TAP cluster.


---
apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
kind: AuthServer
metadata:
  name: my-authserver-example
  namespace: default
  labels:
    name: my-first-auth-server
    env: tutorial
  annotations:
    sso.apps.tanzu.vmware.com/allow-client-namespaces: "default"
    sso.apps.tanzu.vmware.com/allow-unsafe-issuer-uri: ""
    sso.apps.tanzu.vmware.com/allow-unsafe-identity-provider: ""
spec:
  replicas: 1
  issuerURI: "http://authserver.example.com"
  tokenSignature:
    signAndVerifyKeyRef:
      name: "authserver-signing-key"
  identityProviders:
    - name: "internal"
      internalUnsafe:
        users:
          - username: "user"
            password: "$2a$10$201z9o/tHlocFsHFTo0plukh03ApBYe4dRiXcqeyRQH6CNNtS8jWK"
---
apiVersion: secretgen.k14s.io/v1alpha1
kind: RSAKey
metadata:
  name: authserver-signing-key
  namespace: default
spec:
  secretTemplate:
    type: Opaque
    stringData:
      key.pem: $(privateKey)
      pub.pem: $(publicKey)

Validate that the auth-server runs, by checking the AuthServer resource’s status. Both the IssuerURIReady and Ready conditions should be False, but all other conditions should be True. This is because your AuthServer is not accessible yet.

kubectl get authservers my-authserver-example -n default -o yaml
# If you want to check which conditions are not ready, you may use jq for example:
kubectl get authserver my-authserver-example -n default -o json | jq ".status.conditions[] | select(.status != \"True\") | .type"
# IssuerURIReady
# Ready

Then, validate that the deployment is responding over HTTP by exposing it:

kubectl port-forward -n default deploy/my-authserver-example-auth-server 7777:8080

And navigating in your browser to http://localhost:7777. There you should see a login page. Log in using username = user and password = password.

💡 The AuthServer spec, in detail

Here is a detailed explanation of the AuthServer you have applied in the above section. This is intended to give you an overview of the different configuration values that were passed in. It is not intended to describe all the ins-and-outs, but there are links to related docs in each section.

Feel free to skip ahead.

Metadata

metadata:
  labels:
    name: my-first-auth-server
    env: tutorial
  annotations:
    sso.apps.tanzu.vmware.com/allow-client-namespaces: "default"
    sso.apps.tanzu.vmware.com/allow-unsafe-issuer-uri: ""
    sso.apps.tanzu.vmware.com/allow-unsafe-identity-provider: ""

The metadata.labels uniquely identify the AuthServer. They are used as selectors by ClientRegistrations, to declare from which authorization server a specific client obtains tokens from.

The sso.apps.tanzu.vmware.com/allow-client-namespaces annotation restricts the namespaces in which you can create a ClientRegistrations targeting this authorization server. In this case, the authorization server will only pick up client registrations in the default namespace.

The sso.apps.tanzu.vmware.com/allow-unsafe-... annotations enable “development mode” features, useful for testing. Those should not be used for production-grade authorization servers.

Lean more about Metadata.

Issuer URI

spec:
  issuerURI: "http://authserver.example.com"

This is the URL that the auth server will serve traffic from. The authorization server will issue tokens containing this issuerURI, and clients will use it to validate that the token comes from a trusted source.

Note: HTTP access is for getting-started development only! Learn more about a production ready Issuer URI

Lean more about Issuer URI.

Token Signature

---
apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
kind: AuthServer
# ...
spec:
  tokenSignature:
    signAndVerifyKeyRef:
      name: "authserver-signing-key"
---
apiVersion: secretgen.k14s.io/v1alpha1
kind: RSAKey
metadata:
  name: authserver-signing-key
  namespace: default
spec:
  secretTemplate:
    type: Opaque
    stringData:
      key.pem: $(privateKey)
      pub.pem: $(publicKey)

The token signing key is the private RSA key used to sign ID Tokens, using JSON Web Signatures, and clients use the public key to verify the provenance and integrity of the ID tokens. The public keys used for validating messages are published as JSON Web Keys at {issuerURI}/oauth2/jwks. When using the port-forward declared in the section above, JWKs are available at http://localhost:7777/oauth2/jwks.

The spec.tokenSignature.signAndVerifyKeyRef.name references a secret containing PEM-encoded RSA keys, both key.pem and pub.pem. In this specific example, we are using Secretgen-Controller, a TAP dependency, to generate the key for us.

Lean more about Token Signature.

Identity providers

spec:
  identityProviders:
    - name: "internal"
      internalUnsafe:
        users:
          - username: "user"
            password: "$2a$10$201z9o/tHlocFsHFTo0plukh03ApBYe4dRiXcqeyRQH6CNNtS8jWK"

AppSSO’s authorization server delegate login and user management to external identity providers (IDP), such as Google, Azure Active Directory, Okta, etc. See diagram at the top of this page.

In this example, we use an internalUnsafe identity provider. As the name implies, it is not* an external IDP, but rather a list of hardcoded user/passwords. As the name also implies, this is not considered safe for production. Here, we declared a user with username = user, and password = password, stored as a BCrypt hash. For production setups, consider using OpenID Connect IDPs instead.

Lean more about Identity Providers.

check-circle-line exclamation-circle-line close-line
Scroll to top icon