One of the great features in TAP Developer Portal (previously TAP GUI) since the initial release, has been the app live view plugin, which can help visualize actuator data from spring based java applications as well as steeltoe based dotnet core applications.

In TAP 1.6, Application Live View (ALV) has been enhanced with 2 key new features

1. Per User RBAC for secure access to sensitive operations
2. Spring native support

Lets dig a bit into each of these enhancements and see what is in store for us in this release!

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: alv-execute-sensitive-op-role
rules:
- apiGroups: ['appliveview.apps.tanzu.vmware.com']
  resources:
  - sensitiveoperationsaccesses
  verbs: ['execute']

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: scott-alv-admin
  namespace: dev-team-1
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: alv-execute-sensitive-op-role
subjects:
- kind: User
  name: "scott@vrabbi.cloud"
  apiGroup: rbac.authorization.k8s.io

Managing SSO for applications is a complex task, and since TAP 1.4, we have had a great feature called AppSSO, which is aimed at helping make the story of SSO integration much easier for developers and operators.

In TAP 1.6, a major effort was put into AppSSO to make it even more streamlined, and simple to use, while also exposing some more new advanced features, which can be very handy when needed.

In TAP 1.6 the main changes in AppSSO include:

1. Cluster Workload Registration Class
2. Cluster Unsafe Test Login
3. Custom Claim Mappings
4. Configurable token expiry settings

Lets go over what each of these improvement entails and what use cases they can help with.

Cluster Workload Registration Class

This integration is extremely exciting to see. With this new API, we can easily integrate AppSSO with Crossplane and the Services Toolkit components to allow for dynamic service provisioning of OIDC clients from an auth server!

It exposes an AuthServer as a ready-to-claim AppSSO service offering, making it really easy for developer to create new clients for an auth server on demand!

When you create a ClusterWorkloadRegistrationClass (cwrc) resource, this will create behind the scenes a Crossplane Composition and a Services Toolkit ClusterInstanceClass.

The composition itself templates out a new CRD which is also part of this new offering caller a WorkloadRegistration.

While in the past we had the ClientRegistration API, the new API, is more portable, and easily can be promoted between environments without changes to the spec, supporting a GitOps approach which is always the preferred approach in the Kubernetes world.

As we have the ability via the service toolkit to limit permissions to users, for specific classes, and each cwrc creates a new class which is tied to a specific auth server, we can easily manage RBAC and permission boundaries for different IDPs we use, in multi tenant scenarios, while still providing a simple and clean UX for a self service offering to our developers which is awesome!

While more complex and advanced feature can be added, lets take a look at a simple example of what this could look like:

apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
kind: ClusterWorkloadRegistrationClass
metadata:
  name: dev-sample
spec:
  base: 
    spec:
      authServerSelector:
        matchLabels:
          env: dev

apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ClassClaim
metadata:
  name: dev-sample-01
spec:
  classRef:
    name: dev-sample
  parameters:
    workloadRef:
      name: my-workload
    redirectPaths:
      - /redirect/uri

As you can see, the new API is extremely simple to use and understand, and can open up some amazing opportunities for offering a truly self service SSO offering to your end users.

While this is great for production, and more advanced setups, in dev environments or POCs, we often simply want something that just works. The above APIs are simple, but still require configuring the auth server and understanding more low level details than we want to deal with in dev environments. This is where the next new feature comes in.

Cluster Unsafe Test Login

This new API is the recommended way to get started with AppSSO in non production environments.

The new CRD ClusterUnsafeTestLogin (cutl) is so simple, it does not even have a spec!

the only element which is configurable is the name.

apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
kind: ClusterUnsafeTestLogin
metadata:
  name: demo

When you apply the above resource to a cluster, a few things will be created for you. First an Auth Server with an internal unsafe IDP will be deployed. next a token signing key will be generated, and finally a ClusterWorkloadRegistrationClass (cwrc) will be created, which will in turn create a ClusterInstanceClass and a Composition as mentioned above.

The auth server is configured in this setup with an http only issuer URI and allows all CORS origins. While this is definitely not a production setup, it makes integrating into your apps much easier, and removes all of the auxiliary issues from the time of development, making it much easier to get started, and to make sure the SSO elements are working for you as expected, and then you can switch to a more production ready setup, with a real backing IDP, more secure CORS configurations and of course TLS only communication.

The auth server which gets deployed as part of a CUTL, includes a single user with the username “user” and the password “password”.

Once you apply a CUTL resource, you can then create a class claim just like with a CWRC as seen above.

apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ClassClaim
metadata:
  name: dev-sample-01
spec:
  classRef:
    name: demo
  parameters:
    workloadRef:
      name: my-workload
    redirectPaths:
      - /redirect/uri

This new API truly makes getting started on integrating SSO into you apps a breeze, and makes the barrier of entry to AppSSO so much lower!

While these past 2 features focused on simplifying the API and consumption of AppSSO, the next 2 improvements are for more advanced use cases, but are truly amazing to see, and actually can be game changers in certain environments.

Lets take a look at the one I am most excited about which is custom claim mappings support!

Custom Claim Mappings

With this new capability, service operators can control which claims appear in an Auth Server issued ID Token, and how to obtain this value from an upstream identity provider.

Recently when working on a project where i needed to test 4 different OIDC providers, i learned that the 4 claims which this specific app needed, only one of them was the same accross the different OIDC providers. While all data was there, every provider named their claims differently (group / groups / group_names / Groups), (full_name, name, fn, Full_Name) and so on.

While this may seem like a simple issue to solve, it actually is not easy, as within an application i need to look at a specific field in an ID Token to extract the data i need to know who this user is, and what permissions they should have.

This issue gets even more complex when working with an upstream IDP which is not OIDC based, such as LDAP or SAML.

With this new feature, we can now at the Auth Server level, perform mappings between upstream fields, and the claims on the Auth Server generated tokens!

for example, if i want to standardize on the name “groups” for my groups claim, yet i am using workspace one which provides this data as “group_names”, i can simply set the following in my Auth Server:

spec:
  identityProviders:
  - name: wso-idp
    openid:
      idToken:
        claims:
          - fromUpstream: "group_names"
            toClaim: "groups"

This simple yet extremely powerful feature is a huge boost to the AppSSO tooling which opens up awesome opportunities for integrations.

While the above works for external IDPs such as OIDC, LDAP and SAML, the configuration for internal unsafe IDPs in an auth server is a bit different, but also easy to configure.

spec:
  identityProviders:
    - name: test-users
      internalUnsafe:
        users:
          - username: joe
            password: "password"
            roles:
              - "dev"
            claims:
              given_name: "joe"
              family_name: "rosenberg"
              middle_initial: "A"
              email: "joe@vrabbi.cloud"
              alt_address: "123 Awesome Street"
          - username: wendy
            password: "password"
            roles:
              - "operator"
            claims:
              alt_address: "456 Cool Street"
              middle_initial: "T"

As you can see here, we simply configure per user, the custom roles and claims they should have in their ID tokens. With this ability, we can easily simulate real world test cases, even when using an internal unsafe IDP!

There is one more new feature in AppSSO in TAP 1.6, which while it may sound less interesting and exciting, it makes the offering more secure and more tunable to whatever your security teams requirements are.

Token Expiry Settings

In TAP 1.6, we now have the ability to configure the token expiry settings at a per auth server level for access, id, and refresh tokens.

The default expirations set by AppSSO are 12 hours for access and id tokens, and 30 days for refresh tokens.

In order to configure these settings, you just need to add the following to your auth server manifest:

spec:
  token:
    accessToken:
      expiry: "5m"
    idToken:
      expiry: "5m"
    refreshToken:
      expiry: "8h"

The time durations can be provided in seconds (s), minutes (m), or in hours (h). this means that for example the default 30 days for refresh tokens is actually set as “720h”.

Summary

As can be seen, a lot of effort was put into AppSSO in this release, making the integration tasks easier and more streamlined, and also improving on the capability set, and adding new and improved functionality to help all personas involved.

I’m really excited about these new features and can’t wait to see them being used in the wild!

The Metadata Store has been a key element in a secure supply chain within TAP since the GA of TAP, and it provides a central location where all CVE data and SBOMs are stored for our source code and images.

In TAP 1.6, we get a great new set of functionality in the metadata store, allowing for us to now have vulnerability reports stored per build and not just a single report per workload image.

This new feature can be extremely beneficial, as it allows us to perform queries and figure out in which version a specific vulnerability was first introduced, as well as a really great ability to understand which CVEs TBS for example with new dependencies was able to solve for us without the need to change anything in our source code!

The aggregated report is not gone, we simply now also have per build reports, giving us the best of all worlds!

While this may seem like a small feature, it actually truly is huge, and is a huge milestone down the path to being able to perform full end to end tracability and attestation for our supply chains, as well as providing a clear and simple API to be able to gain truly important insights on the development flows within our organization.

This new functionality, combined with the new data being included in the Metadata Store DB via AMR, can open up endless opportunities for data driven decision making and reporting for TAP, which simply has not been possible till today.

Summary

While this new functionality is API/CLI accessible only today, I truly hope to see this integrated into a UI flow in a future release, where we could do diffs between reports of an image and gain clear visibility of the changes between specific image builds in a clear and concise manner!