Configuring Single Sign-On in MMS
Overview
OpenID Connect is an authentication protocol based on the OAuth 2.0 family of specifications. TIBCO Streaming Model Management Server (MMS) supports OpenID Connect for Kubernetes deployments. This allows MMS to authenticate users without having to own and manage password files.
With Single Sign-On enabled through the artifact-management.conf
file stored in the ConfigMap named artifact-management
, users can sign
into the MMS client through a supported OpenID Connect provider.
MMS supports the following OpenID Connect providers:
- Azure AD
- Amazon Cognito
- Okta
For Single Sign-on to MMS to succeed, MMS requires a client ID and a client secret to be obtained from the OpenID Connect provider and be configured in the MMS configuration file.
SSO Configuration Details
The following is a section of the artifact-management.conf
configuration file that
defines how to use OpenID Connect for Single Sign-on. For more
information regarding supported properties, see the MMS Configuration Guide.
security:
auth:
jwtRealm:
jwtIdentityAttributeName: "emailAddress"
jwtRoleAttributeName: "roles"
jwtAudience: "myAudience"
jwtIssuer: "myIssuer"
jwksURL: "http://my.company.com/public-keys.jwks"
jwksCacheTimeoutSeconds: 3600
jwtHTTPHeaderName: "Authorization"
ssoLogoutURL: "https://my-server.mycompany.com/oauth2/sign_out?rd=https://my-server.mycompany.com/"
The following table provides a short description of each property:
Property | Description |
---|---|
auth |
Built-in administrative group name. |
jwtRealm |
Configuration of an authentication and authorization realm that uses JWT and Single Sign-on. |
jwtIdentityAttributeName |
Name of the JWT attribute that holds the principal's identity. |
jwtRoleAttributeName |
Name of the JWT attribute that holds the roles of which the principal is a member. |
jwtAudience |
If present, incoming JWTs must have an audience claim that matches this value. |
jwtIssuer |
If present, incoming JWTs must have an issuer claim that matches this value. |
jwksURL |
Access URL for JWKS resources. |
jwksCacheTimeoutSeconds |
Cache timeout in seconds for cached JWKS resources. |
jwtHTTPHeaderName |
Name of an HTTP header that holds a JWT to validate. |
ssoLogoutURL |
A URL, which when sent with a GET request, logs the current user out of their SSO environment. |
User Roles and Permissions
In MMS, permissions are controlled by user group memberships (roles), and permission bindings on
objects including spaces, sandboxes, projects, and artifacts. Permission bindings are a
mapping of group names to granted permissions. In the initial release, only the permission bindings
on the configured spaces are exposed/configurable. These are in the artifact management server's
configuration file, which is in a Kubernetes ConfigMap named artifact-management
. Sandboxes and
projects are created with default permission bindings which grant full control to all groups to
which a user belongs. This allows collaboration on sandboxes and projects - users who share a
common group can see and edit one another's sandboxes and projects.
In a cloud installation with Oauth2 authentication, group memberships/roles must be provided to MMS by the authentication provider in the authentication token as a list attribute. All users must have at least one assigned role. The default role name varies by provider and can be seen in the installer's helm values:
helm show values kubernetes-installer-${installerVersion}.tgz
For example, for Azure, the helm value is oauth2.azure.roleAttributeName
and the default value
is roles
.
The MMS artifact management server has a defined administrator group with the default name admin
.
Any user in this group (i.e., with this role assigned) is an administrator in MMS and can view and
edit all objects in the system. The admin group name is configurable during installation with the
helm value artifactManagement.security.auth.adminGroup
. The configured admin group is in the
server configuration file in the artifact-management
ConfigMap.