SAS Viya SCIM Configuration

3 Likes

In this article we will continue looking at the System for Cross-domain Identity Management (SCIM) and SAS Viya. In my previous article, SCIM and SAS Viya, we looked at the requirements and considerations for using SCIM. This time we will examine the configuration that needs to be completed within SAS Viya. In following articles we’ll look at the configuration that is completed in the SCIM clients (either Azure Active Directory or OKTA).

As we’ve stated in the previous post, the SCIM client must be registered with SAS Logon Manager and a long lifetime bearer token generated using the client credentials. The type of SCIM client, either Azure Active Directory or OKTA, makes no difference. The bearer token we generate will be provided to the SCIM client and will be used by that SCIM client to authenticate to the SCIM endpoints provided by the Identities microservice. At no point does it matter which SCIM client is used. The client can be registered either using the SAS Viya CLI or by using the REST API. We will provide an example here using the REST API with SAS Viya 2020.1 (and later).

Disable LDAP Provider

Remember the use of LDAP and SCIM in the same environment is not supported. As such the LDAP Provide must be disabled. The following changes could be performed in SAS Environment Manager. However, we will use the SAS Viya CLI instead. The spring configuration for Identities microservice must be updated to remove identities-ldap from the profiles.active setting. Then the sas.identities.providers configuration must be created with ldap.enabled set to false and scim.enabled set to true.

Use the following command to create the JSON file that will define the changed configuration:

tee  ~/DisableLDAP.json > /dev/null << EOF
{
"name": "DisableLDAP",
"items": [
    {
    "version": 1,
    "metadata": {
        "isDefault": false,
        "services": ["identities"],
        "mediaType": "application/vnd.sas.configuration.config.spring+json;version=1"
    },
    "profiles.active": "identities-local"
    },
    {
    "version": 1,
    "metadata": {
        "isDefault": false,
        "services": ["identities"],
        "mediaType": "application/vnd.sas.configuration.config.sas.identities.providers+json;version=1"
    },
    "ldap.enabled": false,
    "scim.enabled": true
    }
]
}
EOF

Use the following commands to use the SAS Viya CLI to apply the configuration, you will need to authenticate as an administrator most probably sasboot:

/opt/sas/viya/home/bin/sas-viya auth login;\
/opt/sas/viya/home/bin/sas-viya configuration configurations create \
--file ~/DisableLDAP.json ;\
/opt/sas/viya/home/bin/sas-viya auth logout

You should see something like the following:

Enter credentials for https://viya.customer.com:
Login succeeded. Token saved.
"POST" "/configuration/configurations" complete from "DisableLDAP.json".
Logout succeeded.

The Identities microservice must now be restarted:

NS={{ViyaNameSpace}}; \
kubectl -n ${NS} scale deployment sas-identities --replicas 0; \
kubectl -n ${NS} wait --for=delete pod -l app=sas-identities --timeout=120s; \
kubectl -n ${NS} scale deployment sas-identities --replicas 1; \
kubectl -n ${NS} wait --for=condition=Ready pod -l app=sas-identities --timeout=120s

You should see something like the following:

deployment.apps/sas-identities scaled
pod/sas-identities-b6c754c75-5m9l5 condition met
deployment.apps/sas-identities scaled
pod/sas-identities-b6c754c75-fljpd condition met

This completes disabling LDAP.

Obtain an Access-Token for Registration

To be able to register our SCIM client with SAS Logon Manager we need to authenticate to SAS Logon Manager. This can either be with an existing client or the Consul token. We will demonstrate using the Consul token.

Use the following command to fetch the Consul token:

NS={{ViyaNameSpace}}; \
CONSUL_TOKEN=`kubectl -n ${NS} get secret sas-consul-client \
-o go-template='{{(index .data "CONSUL_HTTP_TOKEN")}}' | base64 -d`

Use the following command to fetch the access-token required for registration:

INGRESS_SUFFIX=$(hostname -f); \
NS={{ViyaNameSpace}}; \
INGRESS_URL=https://${NS}.${INGRESS_SUFFIX}
ACCESS_TOKEN=`curl -sk -X POST "${INGRESS_URL}/SASLogon/oauth/clients/consul?callback=false&serviceId=scim.idp" \
    -H "X-Consul-Token: $CONSUL_TOKEN"| awk -F: '{print $2}'|awk -F\" '{print $2}'`
echo "The registration access-token is: " ${ACCESS_TOKEN}

You will see something like the following:

The registration access-token is:  eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vbG9jYWxob3N0L1NBU0xvZ29uL3Rva2VuX2tleXMiLCJraWQiOiJsZWdhY3ktdG9rZW4ta2V5IiwidHlwIjoiSldUIn0.
eyJqdGkiOiIxMDdhOWU5MGIwMmY0MDUyYTAwNjU5ZjExMTFiNjRmOSIsInN1YiI6InNhcy5hZG1pbiIsImF1dGhvcml0aWVzIjpbImNsaWVudHMucmVhZCIsImNsaWVudHMuc2VjcmV0IiwidWFhLnJlc291cmNlIiwiY2x
pZW50cy53cml0ZSIsInVhYS5hZG1pbiIsImNsaWVudHMuYWRtaW4iLCJzY2ltLndyaXRlIiwic2NpbS5yZWFkIl0sInNjb3BlIjpbInVhYS5hZG1pbiJdLCJjbGllbnRfaWQiOiJzYXMuYWRtaW4iLCJjaWQiOiJzYXMuYW
RtaW4iLCJhenAiOiJzYXMuYWRtaW4iLCJncmFudF90eXBlIjoiY2xpZW50X2NyZWRlbnRpYWxzIiwicmV2X3NpZyI6ImM3NjM5NmRmIiwiaWF0IjoxNjA3NDQ2NDgyLCJleHAiOjE2MDc0ODI0ODIsImlzcyI6Imh0dHA6L
y9sb2NhbGhvc3QvU0FTTG9nb24vb2F1dGgvdG9rZW4iLCJ6aWQiOiJ1YWEiLCJhdWQiOlsic2FzLioiLCJ1YWEiLCJzYXMuYWRtaW4iXX0.ajTK66GQA-Rb6Qg0jhjW_4ApJUz5pnEVQlrXUU8h4UPM-BKZ_4kC1j4jqtx2
W8e0CpkkiVk58E5mrY_6SqYzRAdX8KOZcWh1Tln2LGMLBocBhneqSlQKmvaBMUfAyTU_ykBEifb1xktJFjUcZodyF4xjCD9Ehx-a7dgmqdWciCbT_mSWjxRjRFvqEitCKvER00fKGK89K2yGCCUrjW7ElfBm3O_VEWjCn8a
2tns_SFIKiwicD_xjMBEbqUJ7sQAQStS1NrqhrxdwHLpJ1RRfH4q1SX7MvH_sq20ZFoJjKmQitn6BvRlmipm_HpSCyzoC5EuyV3SN0pi80VWELxepwg

This access-token can now be used to register our scim.idp client of SAS Logon Manager. This access-token is valid for 10 hours and will allow us to create or delete clients of SAS Logon Manager. It should be kept secure, and only used for the next step.

Register New Client

We will use the access-token we have just obtained to register our new scim.idp client. Use the following command to register the new scim.idp client:

curl -k -X POST "${INGRESS_URL}/SASLogon/oauth/clients" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-d '{
    "client_id": "scim.idp",
    "client_secret": "idpsecret",
    "scope": ["openid","*"],
    "resource_ids": "none",
    "authorities": ["uaa.none"],
    "authorized_grant_types": ["client_credentials"],
    "access_token_validity": 473040000
}'

You should use a complex, randomly generated value for the client_secret, and not the "idpsecret" value we have used here for the example.

You should see something like the following:

{"scope":["openid","*"],"client_id":"scim.idp","resource_ids":["none"],"authorized_grant_types":["client_credentials"],
"autoapprove":[],"access_token_validity":473040000,"authorities":["uaa.none"],"lastModified":1607446598157,"required_user_groups":[]}

This has registered our new client scim.idp with the following details:

The name of the client is: client_id = scim.idp
The client secret, like a password for the client, is: client_secret: idpsecret
The scope is the groups that will be included in the access-token we obtain for the client
The authorization_grant_types defines the type of authentication for this client, and that is only client_credentials so it cannot authenticate end-users
The option access_token_validity defines how long the access-tokens generated for the client will be valid, the default is 12 hours so 43200 seconds, we have used 473040000 which is 15 years

This completes registering the new sim.idp client.

Obtain an Access-Token

Now that we have registered the scim.idp client we can obtain an access-token for the client.

Use the following command to obtain an access-token for scim.idp client using the client_credentials grant:

ID_TOKEN=`curl -skX POST "${INGRESS_URL}/SASLogon/oauth/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-u "scim.idp:idpsecret"| awk -F: '{print $2}'|awk -F\" '{print $2}'`
echo "The client access-token is: " ${ID_TOKEN}; \
echo ${ID_TOKEN} > ~/idtoken.txt

Remember your client_secret will be something more complex than "idpsecret".

You should see something like the following:

The client access-token is:  eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vbG9jYWxob3N0L1NBU0xvZ29uL3Rva2VuX2tleXMiLCJraWQiOiJsZWdhY3ktdG9rZW4ta2V5IiwidHlwIjoiSldU
In0.eyJqdGkiOiI5N2UxOGQwZTczNmQ0MmQ0YTc5YmZmNTBiNTI1OWRmNyIsInN1YiI6InNjaW0uaWRwIiwiYXV0aG9yaXRpZXMiOlsidWFhLm5vbmUiXSwic2NvcGUiOlsidWFhLm5vbmUiXSwiY2xpZW50X
2lkIjoic2NpbS5pZHAiLCJjaWQiOiJzY2ltLmlkcCIsImF6cCI6InNjaW0uaWRwIiwiZ3JhbnRfdHlwZSI6ImNsaWVudF9jcmVkZW50aWFscyIsInJldl9zaWciOiJmMGZmZDgxMCIsImlhdCI6MTYwNzQ0Nj
kxNSwiZXhwIjoyMDgwNDg2OTE1LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0L1NBU0xvZ29uL29hdXRoL3Rva2VuIiwiemlkIjoidWFhIiwiYXVkIjpbInNjaW0uKiIsInNjaW0uaWRwIl19.SFlmKgw1So56hr
C-IhlbquZ7LbiD-LjQRuSGoiRtbhWkYhRh3gFj3uqd7gLaJ-Mmb3efHzqogXpsjWpISiHhCGu2I2mbFDfcB_Co3woLY-F08lOhWQxpi1Bumth7bD-IfAeTA-gN8D9wJNC1vUp_qPfufYLq1l-r3SOWo0vg9qi
BR3lEnRiv0uo1jh2_YXHRTNGnNhJv7_L4hRUaJZsri9GxY0ZDJXMg2tLAzk_BpyDkCYuXaMfiO4dwguhn3f9WOKz8XKYP_6hlFlAr-SY090dmArzjoVmYfNMgFuXfRHHke8tKALJ_3vTnDXSyMvo6aYYLsRSh
RvLL0m9rQile6A

You could then use an online tool like: https://jwt.io/#debugger-io to validate the contents of the token. You should notice the following:

The scope and authorities are both uaa.none
The client_id, cid, and azp are all scim.idp
The expiry of the access-token will be in 15 years’ time, this can be checked using https://www.epochconverter.com/ and the value for exp

This access-token will be used by the SCIM client to authenticate to the Identities microservice SCIM endpoints. As such it will be required for the configuration of the SCIM client and you must keep this safe and secret.

Grant Authorization

Before the SCIM client can be configured the scim.idp client must be granted authorization on the SCIM endpoints of the Identities microservice. By default, SAS Logon Manager clients are not able to access anything within SAS Viya. The authorization rule can be defined in SAS Environment Manager, but we will use the SAS Viya CLI.

Use the following commands to create the new authorization rule, you will need to authenticate as an administrator to the SAS Viya CLI:

/opt/sas/viya/home/bin/sas-viya auth login; \
/opt/sas/viya/home/bin/sas-viya authorization grant --object-uri "/identities/scim/v2/**" \
--description "SCIM Client Access" --permissions "read,delete,create,update" --user "scim.idp"; \
/opt/sas/viya/home/bin/sas-viya auth logout

You should see something like the following:

Enter credentials for https://viya.customer.com:
Login succeeded. Token saved.
{
    "createdBy": "sasboot",
    "creationTimestamp": "2020-12-08T17:14:46.612Z",
    "description": "SCIM Client Access",
    "id": "701c6415-4201-4970-864c-d0984dd13db4",
    "mediaType": "",
    "modifiedBy": "sasboot",
    "modifiedTimestamp": "2020-12-08T17:14:46.612Z",
    "objectUri": "/identities/scim/v2/**",
    "permissions": [
        "read",
        "delete",
        "create",
        "update"
    ],
    "principal": "scim.idp",
    "principalType": "user",
    "reason": "",
    "type": "grant",
    "version": 10
}
The authorization rule has been created.
Logout succeeded.

This completes creating the authorization rule for the scim.idp client.

Validate Access for SCIM Client

We can validate that everything is setup ready for the configuration of the third-party SCIM client. We should be able to access the SCIM endpoints for the Identities microservice using the access-token generated for the scim.idp client.

Use the following commands to use the access-token generated earlier to access the /identities/scim/v2/Users endpoint:

INGRESS_SUFFIX=$(hostname -f); \
NS={{ViyaNameSpace}}; \
INGRESS_URL=https://${NS}.${INGRESS_SUFFIX}; \
ID_TOKEN=`cat ~/idtoken.txt`; \
curl -v "${INGRESS_URL}/identities/scim/v2/Users" \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "Authorization: Bearer $ID_TOKEN"

You should see something like the following:

  * About to connect() to viya.customer.com port 443 (#0)
  *   Trying 10.96.12.144...
  * Connected to viya.customer.com (10.96.12.144) port 443 (#0)
  * Initializing NSS with certpath: sql:/etc/pki/nssdb
  *   CAfile: /home/cloud-user/project/deploy/gelenv/site-config/security/cacerts/ca_cert.pem
    CApath: none
  * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  * Server certificate:
  *       subject: (nil)
  *       start date: Dec 07 07:00:43 2020 GMT
  *       expire date: Mar 07 07:00:43 2021 GMT
  *       common name: (nil)
  *       issuer: CN=GEL Env Intermediate CA,OU=GEL Env Intermediate CA,O=SAS,ST=North Carolina,C=US
  > GET /identities/scim/v2/Users HTTP/1.1
  > User-Agent: curl/7.29.0
  > Host: viya.customer.com
  > Accept: */*
  > Content-Type: application/x-www-form-urlencoded
  > Authorization: Bearer eyJhbGciOiJSUzI1NiIsImprdSI6Imh0dHBzOi8vbG9jYWxob3N0L1NBU0xvZ29uL3Rva2VuX2tleXMiLCJraWQiOiJsZWdhY3ktdG9rZW4ta2V5IiwidHlwIjoiSldUIn0.eyJqdGkiOiI5N2UxOGQwZTczNmQ0MmQ0YTc5YmZmNTBiNTI1OWRmNyIsInN1YiI6InNjaW0uaWRwIiwiYXV0aG9yaXRpZXMiOlsidWFhLm5vbmUiXSwic2NvcGUiOlsidWFhLm5vbmUiXSwiY2xpZW50X2lkIjoic2NpbS5pZHAiLCJjaWQiOiJzY2ltLmlkcCIsImF6cCI6InNjaW0uaWRwIiwiZ3JhbnRfdHlwZSI6ImNsaWVudF9jcmVkZW50aWFscyIsInJldl9zaWciOiJmMGZmZDgxMCIsImlhdCI6MTYwNzQ0NjkxNSwiZXhwIjoyMDgwNDg2OTE1LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0L1NBU0xvZ29uL29hdXRoL3Rva2VuIiwiemlkIjoidWFhIiwiYXVkIjpbInNjaW0uKiIsInNjaW0uaWRwIl19.SFlmKgw1So56hrC-IhlbquZ7LbiD-LjQRuSGoiRtbhWkYhRh3gFj3uqd7gLaJ-Mmb3efHzqogXpsjWpISiHhCGu2I2mbFDfcB_Co3woLY-F08lOhWQxpi1Bumth7bD-IfAeTA-gN8D9wJNC1vUp_qPfufYLq1l-r3SOWo0vg9qiBR3lEnRiv0uo1jh2_YXHRTNGnNhJv7_L4hRUaJZsri9GxY0ZDJXMg2tLAzk_BpyDkCYuXaMfiO4dwguhn3f9WOKz8XKYP_6hlFlAr-SY090dmArzjoVmYfNMgFuXfRHHke8tKALJ_3vTnDXSyMvo6aYYLsRShRvLL0m9rQile6A
  >
  < HTTP/1.1 200
  < Server: nginx/1.19.1
  < Date: Tue, 08 Dec 2020 17:38:05 GMT
  < Content-Type: application/scim+json;charset=UTF-8
  < Transfer-Encoding: chunked
  < Connection: keep-alive
  < Set-Cookie: sas-ingress-nginx=e1332d40e781d8182e79bf9aa3254351; Path=/identities/; Secure; HttpOnly
  < Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' *.sas.com blob: data:; style-src 'self' 'unsafe-inline'; child-src 'self' blob: data: mailto:;
  < X-Content-Type-Options: nosniff
  < X-XSS-Protection: 1; mode=block
  < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  < Pragma: no-cache
  < Expires: 0
  < Strict-Transport-Security: max-age=15724800; includeSubDomains
  < X-Frame-Options: SAMEORIGIN
  <
  * Connection #0 to host viya.customer.com left intact
  {"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],"startIndex":0,"itemsPerPage":0,"totalResults":0,"Resources":[]}

This validates that the access-token is correct, and that the authorization rule is correct allowing the scim.idp client access to the endpoint.

At this point the SAS Viya environment is correctly configured for the SCIM client. Further configuration will be within the interface for the SCIM client, either Azure Active Directory or OKTA. We will look at these configuration settings in the next posts.

Conclusion

We have demonstrated the simple, one-time, steps that must be completed to make the SAS Viya environment ready for the SCIM client configuration. In future posts we will explore in detail the configuration of the different SCIM clients, either Azure Active Directory or OKTA.

mkongoDEV · ‎04-22-2022

Super programmer pour les développeurs dans se rechercher!!!