Configure Azure AD with Open ID Connect

DISCLAIMER

This page contains third-party references. We strive for our content to always be up-to-date, however, the content referring to external vendors may change independently of Omada. If you spot any inconsistency, please report it to our Helpdesk.

To configure Azure AD with Open ID Connect:

1. Open the Azure Portal and select Azure Active Directory.

   

2. Select App registrations, then click + New registration.

   

3. Type a name and a URL for the Omada Identity website. Select Accounts in the organizational directory only in the Supported account types, provide Redirect URI and click Register.

   

4. If not provided in the previous step, in the Authentication blade, enter the URL to the Web Page logon.aspx in the external Web Site. Under the Implicit grant section, mark the ID tokens option.

   

5. To redirect the users who log out to the correct logoff page, add also the URL to the logoff page in the Logout URL field and set the customer setting OpenIDLogoutRedirect to True.

6. Open the Application Overview and copy the ApplicationClosed ID. Copy the value into the tblCustomerAuth.IdpAudience field in the Omada Identity database.

   

7. Go to the list of registered applications and click Endpoints. Find the OpenID Connect Metadata document, and copy this value.

   

8. Paste the copied value into tblCustomerAuth.IdpEndPoint.

   

9. For the OAuth concept to work, edit the Manifest of the main Application registration. Set the value of accessTokenAcceptedVersion to 2.

   

Configure an application to expose a web API

By registering your web API and exposing it through scopes, you can provide permissions-based access to its resources to authorized users and client apps that access your API.

Register the web API

To provide scoped access to the resources in your web API, you first need to register the API with the Microsoft identity platform.

1. Register an application.

2. Skip the Add a redirect URI and Configure platform settings section. You do not need to configure a redirect URI for a web API since no user is logged in interactively.

3. Skip the Add credentials section for now. Only if your API accesses a downstream API would it need its own credentials.

Add a scope

The code in a client application request permission to perform operations defined by your web API by passing an access token along with its requests to the protected resource (the web API). Your web API then performs the requested operation only if the access token it receives contains the scopes required for the operation.

First, follow these steps to create an example scope named Employees.Read.All:

1. Sign in to the Azure portal.

2. If you have access to multiple tenants, use the Directory + subscription filter in the top menu to select the tenant containing your client app's registration.

3. Select Azure Active Directory > App registrations, and select your API's app registration.

4. Select Expose an API > Add a scope.

   

5. You are prompted to set an Application ID URI if you haven't configured one yet.

6. Next, specify the scope's attributes in the Add a scope pane. For this walk-through, you can use the example values or specify your own.

Field	Description	Example
Scope name	The name of your scope. A common scope naming convention is resource.operation.constraint.	Employees.Read.All
Who can consent	Whether this scope can be consented to by users or if admin consent is required. Select Admins only for higher-privileged permissions.	Admins and users
Admin consent display name	A short description of the scope's purpose that only admins will see.	Read-only access to Employee records.
Admin consent description	A more detailed description of the permission granted by the scope that only admins will see.	Allow the application to have read-only access to your Employee records.
User consent display name	A short description of the scope's purpose. Shown to users only if you set Who can consent to Admins and users.	Read-only access to your Employee records.
User consent description	A more detailed desciption of the permission granted by the scope. Shown to users only if you set Who can consent to Admins and users.	Allow the application to have read-only access to your Employee data.

7. Set the State to Enabled, and then select Add scope.

8. (Optional) To suppress prompting for consent by users of your app to the scopes you have defined, you can pre-authorize the client application to access your web API. Pre-authorize only those clients applications you trust since your users won't have the opportunity to decline consent.

   • Under Authorized client applications, select Add a client application.
   • Enter the Application (client) ID of the client application you want to pre-authorize.
   • Under Authorized scopes, select the scopes for which you want to suppress consent prompting, then select Add application.
   info

   If you followed this optional step, the client app is now pre-authorized client app (PCA), and users won't be prompted for their consent when signing in to it.

Add a scope requiring admins consent

Add another example socpe named Employees.Write.All that only admins can consent to. Scopes that requires admin consent are typically used for providing access to higher-privileged operations, and often by client applications that runs as backend services or daemons that don't sign in a user interactively.

Field	Example value
Scope name	Employess.Write.All
Who can consent	Admins only
Admin consent display name	Write access to Employee records.
Admin consent description	Allow the application to have write access to all Employee data.
User content display name	None (leave empty)
User content description	None (leave empty)

Verify the exposed scoped

If you have successfully added both example scopes described in the previous sections, they will appear in the Expose an API pane of your web API's app registration.

As shown in the image, a scope's full string is the concatenation of your web API's Application ID URI and the scope's Scope name.

For example, if your web API's application ID URI https://contoso.com.api and the scope name is Employess.Read.All, the full scope is: https://contoso.com/api/Employees.Read.All.

info

In some cases, it may happen that the access token returned from Azure AD contains a different issuer claim (sts.windows.net) than the one defined in the OpenID metadata document (login.microsoftonline.com). To mitigate this, you need to add the application scope. To do so:

• Click Application ID URI on the application screen.
• Add the scope using the format: api://{application id}.

Now, when making a token request, you need to set this value in the scope parameter: api://{application id}/.default.

Assign users to an application

Prerequisites

To assign users to an app that you added to your Azure AD tenant, you need:

• An Azure account with an active subscription.

• One of the following roles: Global Administration, Cloud Application Administrator, Application Administrator, or owner of the service principal.

• Optional: Completion of View your apps.

• Optional: Completion of Add an app.

• Optional: Completion of Configure an app.

info

Use a non-production environment to test the steps in this section.

Assign users

Follow these steps to assign users to an application:

1. In the Azure AD portal, select Enterprise applications. Then find and select the application you want to configure.

2. In the left navigation menu, select Users and groups.

   note

   Some of the Microsoft 365 apps require the use of PowerShell.

3. Select the Add user/groups button.

4. On the Add Assignment pane, select Users and groups.

5. Select the user or group you want to assign to the application. You can also start typing the name of the user or group in the search box. You can choose multiple users and groups, and your selections will appear under Selected items.

   info

   When a group is assigned to an application, only users in the group will have access. The assignment does not cascade to nested groups.

   note

   Group-based assignment requires Azure Active Directory Premium P1 or P2 edition. Group-based assignment is supported for Security groups only. Nested group membership and Microsoft 365 groups are not currently supported. For more licensing requirements for the features discussed in this section, see the Azure Active Directory pricing page.

6. When finished, click Select.

   

7. On the Users and groups pane, select one or more users or groups from the list and then click the Select button at the bottom of the pane.

8. If the application supports it, you can assign a role to the user or group. On the Add Assignment pane, click Select Role. Then, choose a role to apply to the selected users or groups, then click OK at the bottom of the pane.

   note

   If the application does not support role selection, the default access role is assigned. In this case, the application manages the level of access users have.

9. On the Add Assignment pane, click the Assign button.

   note

   You can unassign users or groups using the same procedure. Select the user or group you want to unassign and then click Remove. Some of the Microsoft 365 and Office 365 apps require the use of PowerShell.