AZ500 - Identity - Part 2

I am currently studying for the AZ 500 exam which focuses on Microsoft Azure Security Technologies. This is the next blog post in that series.

The first major section in the Az500 exam is focused on managing identity and access. The goal of this post is to talk about apps and app registrations. It would be hard to dive in to a discussion on apps without talking about OATH 2.0, the underlying protocol that this feature supports.

An OAUTH 2.0 Primer

Fundamentally, OAUTH 2.0 is a delegation protocol. What this means is that owners of a resource (or data, or system, or whatever) can use this protocol to delegate permissions (or a subset there of) to another entity. In the olden days, we used to accomplish this by having applications impersonate the user itself and then use that impersonation to access protected resources. There are many security weaknesses to performing impersonation, and the OAUTH 2.0 protocol is an effective way to still provide this service without performing impersonation.

Key Terms

Lets go over some key terms for OAUTH.

Protected Resource: The resource/service/data that needs to be accessed and is protected by authentication and authorization mechanisms.

Resource Owner: This is the person who owns (or who was given access to) a protected resource. This is generally a user and is typically referred to as the user agent.

Client Application: This is likely the most confusing term in OAUTH. In this case, the client application is the application/service that will be accessing the protected resource on behalf of the resource owner. In most cases, this is the web service you are talking to. In well built native applications, this would be the native application itself. In much of the literature on the subject, this is referred to as the “client”.

Authorization Server: A service that is trusted by the protected resource to issue special-purpose security credentials (or OAUTH Tokens) to a client application on behalf of a user. Typically, the authorization server authenticates a resource owner and then, based on policy definition, issues special tokens with the appropriate authorizations to the client application.

The OAUTH 2.0 Dance

Due to the number of moving pieces in our connected world, there is a “dance” that all systems must go through to successfully use OAUTH. This dance is required as it effectively pushes security decisions to the entity that has the most context for that decision, the user. While the framework is extensible, there following are high level steps that occur.

Step 1) The client requires access to a protected resource, and requests, from the resource owner, appropriate permissions. This is generally manifested in the form of a url redirect to the authorization server for a particular resource.

Step 2) The authentication server authorizes the resource owner. Based on parameters passed to it, it prompts the user to allow a particular client a set of permissions (ie: scopes) to a protected resource. The resource owner authorizes the client. When this is complete, a code is provided to the resource owner, which is then provided to the client. This is generally manifested as a URL redirect as well. (Please note that this describes the authorization code grant flow, only 1 of the possible flows in OAUTH).

Step 3) The client sends the authorization code it received from the resource owner to obtain an authorization token that is valid for the protected resource. This token is limited to the identity and the scopes as provided/verified by the resource owner.

Step 4) The client application uses the authorization token it has received to access the protected resource. The protected resource validates the authorization token before providing final access.

So what exactly are app registrations in Azure AD?

App registrations are how client applications (using the OAUTH definition above) register themselves with the authorization server. This is an important process because, in step 2 of the OAUTH dance above, the client application has to authenticate itself with the authorization server in order to convert a code to an authorization token. This is done by passing a client id and client password combination to the authorization server, which is effectively what an application registration is.

More specifically, according to the Microsoft documentation, an application registration generates two objects in your Azure Active Directory. The first is the application object itself, which is basically meta-data about the application. The second is a service principal object, which is effectively how the application authenticates/authorizes itself to a given tenant. Importantly, there is one application object for a representation of an application, but there can be several service principals assigned to that application object.

How do you register an application?

Part of the AZ500 exam will test if you understand how to create resources. In order to create an application registration, you can follow the steps documented here (https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal) and https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app.

A couple of notes:

• On the first page, you will need to understand what type of “application” you are creating. Typically, you’ll create a single tenant application. What this means is that only users of the tenant that the application object is registered to can use the application. The other two types represent multi-tenant applications, one extending to other Azure Active Directory tenants, and the other doing that + Microsoft personal accounts.
• The redirect URI is the URI that the authentication response will go to on success. This is effectively step 2 of the OAUTH dance above. It is extremely important that you enter in a specific/selective URI here as there are a few attacks against the redirect URI that can result in token compromise. For some guidance on this, please see https://docs.microsoft.com/en-us/azure/active-directory/develop/reply-url

Whose scope is it anyways?

In OAUTH2, scopes are effectively the permission set of the client (or in this case, the application registration) against a given API or protected resource. In general, clients can request any scope they would like. Scopes can be administrative configured in the authorization server, and, generally, clients can chose to grant or deny specific scopes at consent time. When a client successfully completes an authentication, it will effectively get an access token that specifies only the allows scopes, which will then be passed to the protected resource for use.

In Azure, there are two types of permissions that can be granted to an application. This is because, as discussed in the OAUTH protocol, you can have applications that function when the user is present, and you can have applications that function when there is no user.

In Microsoft speak, delegated permissions are used by applications that have a signed-in user present. For these applications, either a user or an administrator (of the tenant) can consent to a set of permissions that the application requests. The effective permission set given to a client/application is the least privileged intersection of the consented to permissions and the permissions of the currently logged in user.

Application permissions are used when the application is expected to function without a logged in user. In this case, the effective permissions set are the application permissions, which can only be administratively set when registering/creating/editing the application.

Instructions on how to add scopes can be found here (https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-permissions-to-access-web-apis).

Consent

We’ve talked a lot about consent, which is a required step in the OAUTH flow. For more information on how to configure consent, please see https://docs.microsoft.com/en-us/azure/active-directory/develop/consent-framework.

Conclusion

In this post we talked a bit about application registrations and what they mean in terms of OAUTH 2.0. We covered a couple of the basics, showed some documentation on how to accomplish application related tasks in the portal, and talked a bit about consent and scopes (required topics).

 

About Shamir Charania

Share This Article

Comments