Hello René,

If you are using Indicium Universal and you have configured at least one OpenID client in IAM, then Indicium's /.well-known/openid-configuration endpoint will be available. Please note that it is necessary to restart Indicium for any changes to OpenID clients in IAM to take effect. You can remove all of the other properties in that configuration section:

authorizationEndpoint
tokenEndpoint
issuer
wellKnownOpenIdConfiguration

The values of the client ID and the client secret can be chosen freely, but they must match on both sides. Please note that the clientSecretSettingName property refers to the name of setting under which the secret is stored, not the value of the secret itself. You will need to configure the client secret that you've entered in IAM in the Azure App Service Application Settings as well and then take the name of that setting.

The URL of the Azure App Service (where you want to go after being signed in successfully) should also be registered as a Redirect URL for that OpenID Client in IAM:

The hardest part to explain is the "login": { ... } part, because what you need to enter here depends on your requirements and the requirements of the application. You mentioned that the website is just static content that needs to be protected by authentication. In that case, I would assume that the login part of the configuration isn't necessary at all. If you simply want a yes/no answer from Indicium to the authentication attempts of users, then you don't need any scopes or claim types.

If you want additional information, such as usernames, email addresses, first name, last name, etc., then the login settings become relevant. For instance when you need to map the authenticated users of the Thinkwise Platform back to the users of the third party, or if you want to create user accounts for them on the fly, using their information from IAM.

I hope this helps.

Hello Vincent,

Many thanks for the advanced answer, it works .

For common interest some tips how to get it working in combination with an App Service (with static content in this case);

• In IAM > OpenID Client > Configuration > Redirects the uri should be something like https://yourwebsite.azurewebsites.net/.auth/login/youridentityprovider/callback
• Don't forget to restart your app service after each change in configuration or files (both IAM and the ‘static client’)
• As mentioned here, you need to set the application setting WEBSITE_LOAD_USER_PROFILE to 1. This can be done in the Azure Portal under the app service > Configuration > Application settings.
• The client secret also must be stored in the app settings (not in IAM, but in the client site)
• If something is not working as expected check the log files in Indicium.
• I've used the following ‘auth.json’ file (see https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-provider-openid-connect and https://anthonychu.ca/post/azure-functions-app-service-openid-connect-auth0/ (section about “Enable file-based auth configuration”) for more information how to set up:

{
    "platform": {
        "enabled": true
    },
    "globalValidation": {
        "redirectToProvider": "thinkwise",
        "unauthenticatedClientAction": "RedirectToLoginPage"
    },
    "identityProviders": {
        "openIdConnectProviders": {
            "thinkwise": {
                "registration": {
                    "clientId": "client_id",
                    "clientCredential": {
                        "secretSettingName": "client_secret"
                    },
                    "openIdConnectConfiguration": {
                        "wellKnownOpenIdConfiguration": "https://yourwebsite.azurewebsites.net/.well-known/openid-configuration"
                    }
                },
                "login": {
                    "nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
                    "scopes":  
                        "openid",
                        "email"
                        ],
                    "loginParameterNames": i]
                }
            }
        }
    },
    "login": {
        "tokenStore": {
            "enabled": false
        }
    }     
}

Hello René,

I'm happy to hear that it's working. Thank you for the additional information on how to configure an Azure App Service as an OpenID client specifically.

Indicium can serve as an OpenID Identity Provider to any client that implements the protocol correctly, but it can be challenging to configure both the server and the client and make them work together. Both sides expect specific values from each other when it comes to URLs, scopes and claim types and since these differ from server to server and client to client, it's hard to document it at a general level.

Perhaps we should write a blog post or dedicate a paragraph in our documentation on how to get this working for Azure App Services specifically, using your insights. This will probably become a fairly common use case for OpenID.