can act as a Relaying Party in the OpenID Connect 1.0 flow. https://openid.net/specs/openid-connect-core-1_0.html
Once you connect with an ID provider and start the desktop launcher, you will see the Log in with SSO option.
Login with SSO option
supports SSO using an OpenID Connect (OIDC) compliant Identity Provider. Microsoft Active Directory can be configured to act as such an Identity Provider. If this for some reason is not applicable, it is also possible to add an OIDC Proxy in front of the Active Directory to enable the OIDC protocol.
can act as a Relaying Party in the OIDC 1.0 flow. Refer for more details: https://openid.net/specs/openid-connect-core-1_0.html.
The conceptual diagram below describe the details of the OIDC SSO authentication flow towards Active Directory.
OIDC SSO Authentication Diagram
Azure as Identity Provider
When Azure is used as an ID provider, ensure to set the property auth.oidc.rp.provider.name to Azure to be able to fetch the groups. The reason for this is that Azure is sending a list of group ids, but needs the Access group name. When ID Provider is Azure it uses the group id to fetch the group name from Azure Graph API endpoint, currently using v1.
Configuration
To turn on the feature a number of properties are added to the values.yaml file. The properties of the file are described below.
rp:
# Activate/deactivate Usage Engine Private Edition as OIDC Relay Party
enabled: false
auth:
# Available auth methods is CLIENT_SECRET_BASIC and PRIVATE_KEY_JWT
method: "CLIENT_SECRET_BASIC"
client:
# Client id
id: ""
# Client secret is only used when the method is CLIENT_SECRET_BASIC
# Uncomment if credentials are not already provided through secret "oidc-rp-secret"
#secret: ""
# JWT section only used when method is PRIVATE_KEY_JWT
jwt:
#Opional ID Provider KeyId
keyId:
jks:
secret:
#Name of secret to store jks
name:
#Key Alias
alias:
#Key password
# Uncomment if credentials are not already provided through secret "oidc-rp-secret"
#password:
#Keystore password
# Uncomment if credentials are not already provided through secret "oidc-rp-secret"
#storePassword:
provider:
# Base URL for Identity Provider
# URL before /.well-known/openid-configuration
# Eg. https://login.microsoftonline.com/<tenant_ID>/v2.0
url:
# Name of Provider, eg. Azure
name: ""
# Path in UserInfo or ID Token to find access groups mapping, separated by dot (.)
# The groups should be a array of Strings.
# *** Example ***
# Here is the groups array inside a object.
# { myObject : { myGroups : [ "myGroup1", "mygroup2" ] } }
# The path should then be:
# groupPath: myObject.myGroups
# When the groups array is direct under UserInfo then groupPath is just the
# name of the groups array.
groupPath:
# Claim to use for Username
userNameClaim:
# Additional scopes
scopes:
The following properties are mandatory.
Property | Description |
|---|---|
| auth.oidc.rp.client.id | Default value "" Client ID provided by Identity Provider. If it is not present, the SSO functionality is disabled. |
| auth.oidc.rp.provider.url | Default value "" Provide the Base URL to the associated Identity Provider. Read access is required for the /.well-known/openid-configuration file to acquire the relevant Provider Configurations. |
| auth.oidc.rp.provider.name | Default value "" The name of the provider needs to be Azure if it is used and groups are returned as uids. |
| auth.oidc.rp.groupPath | Default value "roles" Path in ID Token or UserInfo object to find an array of users Access groups as defined by the Access Controller, separated with a dot (.). |
| auth.oidc.rp.auth.method | Default value "CLIENT_SECRET_BASIC" Available authentication methods are CLIENT_SECRET_BASIC and PRIVATE_KEY_JWT |
The following properties are mandatory when CLIENT_SECRET_BASIC is used as an authentication method:
Property | Description |
|---|---|
| auth.oidc.rp.client.secret | Default value "" This property sets the relevant Client Secret. |
The following properties are mandatory when PRIVATE_KEY_JWT is used as an authentication method:
Property | Description |
|---|---|
| auth.oidc.rp.auth.jwt.keystorePath | Default value "" Path to JKS keystore when PRIVATE_KEY_JWT is used |
| auth.oidc.rp.auth.jwt.alias | Default value "" Alias for key in keystore when PRIVATE_KEY_JWT is used |
auth.oidc.rp.auth.jwt.keystorePassword | Default value "" Keystore password when PRIVATE_KEY_JWT is used, needs to be Encrypted by MediationZone |
| auth.oidc.rp.auth.jwt.keyPassword | Default value "" Key password when PRIVATE_KEY_JWT is used, needs to be Encrypted by MediationZone |
The following properties are optional:
Property | Description |
|---|---|
| auth.oidc.rp.scopes | Default value "" Optional additional scopes. Default scopes are openid, profile, and email. |
| auth.oidc.rp.claims.username | Default value "" Claim to use as the user name, if not specify sub will be used. This value should be unique. |
| auth.oidc.rp.auth.jwt.keyId | Default value "" Optional Key ID for JWT header when PRIVATE_KEY_JWT is used |
Kubernetes Secret
Credentials can be written into a Secret object named env-secrets prior to installation.
Example - Secret object
$ kubectl create secret generic oidc-rp-secrets -n <namespace> \ --from-literal=keystorePassword="<password>" \ --from-literal=keyPassword="<password>" \ --from-literal=clientSecret="<secret>"
Helm Values
Credentials can also be provided through values to Helm, by providing them in values.yaml or by passing them on the command line.
Example - Helm credentials
$ helm install <release_name> ./usage-engine-private-edition --wait --timeout=5m --namespace <namespace> \ --set auth.oidc.rp.auth.jwt.jks.storePassword="<password>" \ --set auth.oidc.rp.auth.jwt.jks.password="<password>" \ --set auth.oidc.rp.auth.client.secret="<secret>"
Private Key Authentication
When method: "PRIVATE_KEY_JWT" is used the section jwt needs to be defined.
In addition to the values in the helm values file, a Java Keystore in JKS format also needs to be created and put into a Kubernetes Secret. The name of the keystore needs to be ssokeystore.jks. The key algorithm needs to be RSA or EC. The signing algorithm of the JWT used to authenticate to the Token Endpoint will be RS256 for RSA keys and ES256 for EC keys.
The script below shows how these can be generated and stored in the Secret. Note that this will generate a self-signed certificate, which is not suitable for use in publicly exposed interfaces. Make sure to set the parameters in the beginning of the script before using. This script produces the ssokeystore.jks and create a secret of it. It also produces the file publicCert.pem, this file should be uploaded to the ID provider in advance.
#!/bin/bash KEY_PASSWORD=DefaultKeystorePWD STORE_PASSWORD=DefaultKeystorePWD DNAME=CN=exampledomain.com,O=Example K8S_NAMESPACE=<namespace> rm -f ssokeystore.jks publicCert.pem keytool -genkey -keystore ssokeystore.jks -storepass $STORE_PASSWORD -keypass $KEY_PASSWORD -alias certificate -keyalg RSA -keysize 2048 -dname $DNAME keytool -keystore ssokeystore.jks -exportcert -alias certificate -rfc -file publicCert.pem -deststorepass $STORE_PASSWORD kubectl create secret generic oidc-cert --namespace $K8S_NAMESPACE --from-file=ssokeystore.jks
Add Comment