Solved

How to use OpenID from IAM for authentication on Azure App Service?

  • 4 February 2021
  • 3 replies
  • 266 views
R
Rank
Userlevel 5
Badge +15

I'm trying to configure an Azure App Service that uses the OpenID possibility of IAM to authenticate users. The app service is a website with static content and should be protected using an OpenID Connect provider:

https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-provider-openid-connect

I’ve tried to set this up, but I struggle with both the configuration in Azure and in IAM.

When I use the example document from Microsoft documentation (below) from Apple ID it does redirect me to the Apple ID login page, on which I assume should work when correctly set up;

{
    "platform": {
        "enabled": true
    },
    "globalValidation": {
        "redirectToProvider": "apple",
        "unauthenticatedClientAction": "RedirectToLoginPage"
    },
    "identityProviders": {
        "openIdConnectProviders": {
            "apple": {
                "registration": {
                    "clientId": "com.contoso.example.client",
                    "clientCredential": {
                        "secretSettingName": "APPLE_GENERATED_CLIENT_SECRET"
                    },
                    "openIdConnectConfiguration": {
                        "wellKnownOpenIdConfiguration": "https://appleid.apple.com/.well-known/openid-configuration"
                    }
                },
                "login": {
                    "nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
                    "scope": [],
                    "loginParameterNames": []
                }
            }
        }
    },
    "login": {
        "tokenStore": {
            "enabled": true
        }
    }     
}

There are some settings that need to be changed, or set up different.

Is this possible to use and what values should be used? The config file is specified over here (section openIdConnectProviders):

https://docs.microsoft.com/en-us/azure/app-service/app-service-authentication-how-to#config-file

"openIdConnectProviders": {
            "<providerName>": {
                "enabled": <true|false>,
                "registration": {
                    "clientId": "<client id>",
                    "clientCredential": {
                        "clientSecretSettingName": "<name of app setting containing client secret>"
                    },
                    "openIdConnectConfiguration": {
                        "authorizationEndpoint": "<url specifying authorization endpoint>",
                        "tokenEndpoint": "<url specifying token endpoint>",
                        "issuer": "<url specifying issuer>",
                        "certificationUri": "<url specifying jwks endpoint>",
                        "wellKnownOpenIdConfiguration": "<url specifying .well-known/open-id-configuration endpoint - if this property is set, the other properties of this object are ignored, and authorizationEndpoint, tokenEndpoint, issuer, and certificationUri are set to the corresponding values listed at this endpoint>"
                    }
                },
                "login": {
                    "nameClaimType": "<name of claim containing name>",
                    "scopes": [
                        "openid",
                        "profile",
                        "email"
                    ],
                    "loginParameterNames": [
                        "paramName1=value1",
                        "paramName2=value2"
                    ],
                }
            },
            //...
        }

I'm not sure if the wellKnownOpenIdConfiguration should be used or that the authorizationEndpoint, tokenEndpoint, issuer etc should be configured.

On the IAM side of this I've only added an OpenID client and added a ‘secret’ under “Configuration”.

Any thoughts about how to solve this?

icon

Best answer by Vincent Doppenberg 4 February 2021, 18:44

View original

3 replies

V
Rank
Userlevel 6
Badge +4

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.

R
Rank
Userlevel 5
Badge +15

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);

{
    "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": []
                }
            }
        }
    },
    "login": {
        "tokenStore": {
            "enabled": false
        }
    }     
}

 

V
Rank
Userlevel 6
Badge +4

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.

Reply


Terms & ConditionsCookie settings