MC Configuration file sdk_config.jwt

The sdk_config.jwt file is only needed for the KOBIL Shift Lite solution. It is signed by AST Services.

via the KOBIL Portal

1. Press 'Create SDK-Config'

2. Add trusted TLS server certificates

Note: This file containing the trusted TLS server certificates must be in PEM format, it can contain one or more certificates. See Trust Store Configuration for details on which certificates to put into the trust store. Note that you need to add certificates for all the services of your Shift Lite environment. In the typical case, most of the services will reside on the same server, so a single certificate in the file can be sufficient (especially if you give the certificate from some common CA on the chain, or when you are using a wildcard certificate for the servers), but in more complex situations, you might need multiple certificates. Also, when renewing certificates and you want to have both old and new certificates in parallel, you will need to put several certificates into the file.

3. Use sdk_config.jwt in your app

The file is not readable without decoding the JWT structure. You can use services like https://jwt.io/ to read and check the values like URLs and trusted TLS server certificates.

Note: Be careful not to change file content and line/file endings, otherwise signature will be broken and cannot be used for Login.

Note: For additional details see KOBIL Portal documentation.

via cURL CLI

Note: All of the described API requests require an authorization token, see Getting Authorization Tokens. While the request to get an authorization token will use the subdomain idp all your App/App Version related requests should use the subdomain asts

Add user to signers

If this was not done before, add the desired user to the list of signers that are allowed to create JWT tokens:

curl -X 'POST' \
  'https://asts.your-environment.shift.company.com/v1/signers' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{   "tenant": "$yourTenantName",   "name": "$userId" }'

your-environment.shift.company.com should be replaced by the suitable host name of your environment. While the request to get an authorization token will use the subdomain idp all other requests should use the subdomain asts.
$yourTenantName should be the tenant for which you want to create the JWT file.
$userId should be the user id of the user who is to be allowed to sign JWT tokens. This should be a UUID-style ID that uniquely identifies the user, not just the user name. This UUID is not normally displayed to the users, but it can be seen in the IAM system where you manage the users (KOBIL IDP).

Create a signed JWT file

An important detail that is provided by the JWT file is the trusted certficate. This must first be formatted in such a way that you can handle it in the cURL request:

1. Assume you have that certificate in form of a standard PEM file Certificate.pem.
   
2. Replace the line breaks in the file by the escape sequence \n and print the result to the command line as a single line of text, e.g. using this command: awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' Certificate.pem
   
3. Strip -----BEGIN CERTIFICATE-----\n and \n-----END CERTIFICATE-----\n
   

Now, you are ready to do a POST request in the following form to get the signed sdk_config.jwt:

curl -o sdk_config.jwt -X POST "https://asts.your-environment.shift.company.com/v1/tenants/$yourTenantName/sdkconfig" \
--header "content-type: application/json" \
--header "Authorization: Bearer $token" \
--data-binary "{
  \"tenant\": \"$tenant\",
  \"tlsBundle\": [ \"$Certificate\"
  ],
  \"astUrl\": \"https://asts.your-environment.shift.company.com\",
  \"services\": [
    {
        \"name\": \"astCa\",
        \"url\": \"https://asts.your-environment.shift.company.com\"
    },
    {
        \"name\": \"astLogin\",
        \"url\": \"https://asts.your-environment.shift.company.com\"
    },
    {
        \"name\": \"astManagement\",
        \"url\": \"https://asts.your-environment.shift.company.com\"
    },
    {
        \"name\": \"astProperties\",
        \"url\": \"https://asts.your-environment.shift.company.com\"
    },
    {
        \"name\": \"astStream\",
        \"url\": \"https://asts.your-environment.shift.company.com\"
    },
    {
        \"name\": \"astTms\",
        \"url\": \"https://asts.your-environment.shift.company.com\"
    },
    {
         \"name\": \"push\",
         \"url\": \"https://scp.your-environment.shift.company.com/notifier\"
    }
  ]
}"

your-environment.shift.company.com should be replaced by the suitable host name of your environment. Again, while the request to get an authorization token will use the subdomain idp all other requests should use the subdomain asts.
$yourTenantName should be the tenant for which you want to create the JWT file.
$token should be an authorization token of a user with the correct permissions / roles to sign a JWT token.
$Certificate must be the a certificate in the chain from the TLS server certificate to the corresponding root CA, here are some details on which certificate to choose. Note that it must be given in the format described above. In the typical case, most of the services will reside on the same server, so a single certificate can be sufficient (especially if you give the certificate from some common CA on the chain, or when you are using a wildcard certificate for the servers), but in more complex situations, you might need multiple certificates. Also, when renewing certificates and you want to have both old and new certificates in parallel, you will need to put several certificates into the file. In such cases you can pass a comma-separated list of certificates, where each certificate needs to be in the format described above, i.e. instead of \"tlsBundle\": [ \"$Certificate\"], you would pass \"tlsBundle\": [ \"$Certificate1\", \"$Certificate2\"],.