AAD

Pre work and project structure

Get Started

Recommended way to create a cluster is via ARM scripts. Cluster can also be created using Azure portal, but many advance features are only available in ARM

Following are pre-requisites before your start provisioning your cluster.

  • Plan for cluster nodes + capacity + OS
  • Plan for placement constraints and node types
  • Securing cluster
    1. Create Azure AD applications – To secure access to cluster it is recommended to use AAD authentication. Create Cluster and client AAD applications. Cluster application will have 2 roles, Admin & ReadOnly to cluster application.
    2. Create cluster management SGs that you will assign to these 2 roles. You would require 2 SGs, one for admins and other for read only access.
    3. Add security groups to you AAD application role. If you work for an enterprise or if you are not Azure AD administrator, adding security group or users to app role is generally not allowed. You would have to request your AAD administrator to add SGs to AAD application roles.
  • Get certificates for SSL, Encryption and any other application certificate that your service needs
    1. make sure you add all alternate names to your cluster certificate during request creation
  • Identify PORTS that will be open on load balancer.
  • Use powershell to create the cluster

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-creation-via-arm

Project Structure

  • API code and service fabric code should not be mixed together in one solution.
  • For example, if you have 2 APIs that you want to containerize and then host on service fabric;
    • You can have one solution with both API code projects added. If you desire more separation, each API can be created as a different project
    • Each project will contain a DOCKERFILE that will define how container image will be created for that respective project
    • Below image shows a solution containing 2 web APIs, Gateway API and User API. Docker support is added to both of these projects using Visual Studio (right click project –> add –> docker support).

    clip_image001

    • None of above 2 projects have any reference or code related to Service Fabric
    • Please note, adding docker support from Visual Studio also adds docker-compose file to your project. Orchestration platforms can either use this docker-compose file to manage container or can use it’s own way. While writing this content, Service Fabric does not fully support docker-compose (https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-docker-compose). For my projects, I will configure orchestration settings directly in my Service Fabric project.
    • Using docker command line tools or visual studio publish features, above 2 projects will result in 2 images that can be pushed to a container registry. For most of my applications I will use Azure Container Registry
    • To use service fabric as an orchestrator for hosting your contained images, we need to create a new Service Fabric project,
      • Create new service fabric project

    clip_image002

    • Add 2 new container services to the SF project. After adding your project should look like this:

    clip_image003

    • Each service will define, Code, Config and Data. Each of this component is versioned independently.
      • Code – Container image information
      • Config – Any settings or environment variables
      • Data – Any static data that is required by the service
    • You can override config values in ApplicationManifest.xml which also allows you to use environment specific parameter files. Typically these parameter files are modified using build release pipeline.
Advertisements

Azure AD–Using App roles for authorization

Role based authorization

In intranet applications, AuthZ is generally implemented using Windows security groups with ASP.NET IsInRole() functionality. Following is a list of steps we take to make this work:

  • Define high level application roles. For example; in an expense application we can have approver and administrator as two roles with higher (or different privileges) than normal user.
  • Identify initial set of Windows security groups that will be mapped to app roles. This list should be dynamic and will probably change.
  • Use a mapping mechanism, either DB or configuration file, to keep a mapping of application roles and security groups.
  • In your application, once you get the token after authenticating the user, write code to check group claim and assign appropriate role claim (based on your mapping) to the user.
  • Indicate to ASP.NET pipeline that you want to use Role claim for IsInRole functionality.
  • That is pretty much it. Now, you can just place Authorize attribute wherever you want to check for that role or call IsInRole() to do the same.

Here comes Azure Active Directory

Now we want to move our on-premises (intranet) application (Windows Auth) to cloud. I’m skipping ADFS (STS) here, as at a high level the claims you get in the SAML token are similar to claims present in Kerberos token.

As of today, recommended service for AuthN and AuthZ on cloud is Azure AD (AAD). Moving your app to AAD bring some challenges as well as provide some opportunities to improve things.

Challenge

  • Tokens that you receive from AAD does not contain group claims by default. You have to enable it using these steps.
  • Even if you enable, there is a limit to groups that you can get in the token. I will not go into those details. Please check this for more info around this. 

Opportunity

  • Did you notice all work that is required to make application roles really work even in traditional (intranet) application?
  • You have to have mechanism to map app roles with security groups, fetch the mapping and add role claim.
  • Just like authentication, all this should ideally be offloaded to some common service.
  • Let’s see how we can improve this.

Solution

AAD provides application roles that can be used for authorization. I’ll show you in detail how it is done. This is a step by step guide and will have lot of screen shots.

Note: Make sure you have a valid subscription before you proceed beyond this point.

Set up your infrastructure

Create User and Group in AAD

  • Select your directory
    1
  • Add 2 users. For example, add a users Bob and add another user Samantha.2
     
  • Add a group.
    3
  • Add Bob to the group.
  • At the end of this step you should have 2 users and a group. One of the user should be part of the group.

Create Application in AAD

  • Add application to the directory using Application option from top menu and then clicking Add link in the bottom menu. For more details use this link.45
  • Give a friendly name, sign on URL and app id URI. For more details use this link.
    67
  • Note down client ID from configuration tab. This we will use in our web app to set up authentication.
    9

Create web app and make authentication work

  • Create a simple ASP.NET MVC web app and update OWIN Auth configuration with your application’s client ID and tenant name.
  • Download completed code from github
  • After updating required values, try to run the sample. I used the Individual account template while creating the project due to which there are few extra files and steps before login. From home page, click login and then click OpenIDConnet button. This will initiate login process with AAD.
  • You can put breakpoint in Contact action method in Home Controller to check available claims. Notice that there is neither group nor role claim.

Add role to AAD application

  • Open application in AAD and download manifest file. Currently, you can not add application roles from portal UI. We will use manifest file to add roles. 10
  • Open manifest in a text editor (preferably JSON editor). App roles will be blank.
  • 11
  • Add following text to app roles section in manifest file. This is the place where we are adding 2 roles.
    “appRoles”: [
                {
                    “allowedMemberTypes”: [
                        “User”
                    ],
                    “description”: “Approvers can mark expenses as approved”,
                    “displayName”: “Approver”,
                    “id”: “8F29F99B-5C77-4FBA-A310-4A5C0574E8FF”,
                    “isEnabled”: “true”,
                    “value”: “approver”
                },
                {
                    “allowedMemberTypes”: [
                        “User”
                    ],
                    “description”: “Administrators can change all settings and do all other operations”,
                    “displayName”: “Administrator”,
                    “id”: “0866623F-2159-4F90-A575-2D1D4D3F7391”,
                    “isEnabled”: “true”,
                    “value”: “administrator”
                }
            ],
  • Resulting manifest should look like this12
  • Upload the manifest back to the application.

Assign group to a role

  • Go to application in AAD and open Users and Group option. Please note, I’m using a premium subscription to do this. In a non premium subscription only user can be assigned to a role. This is just a UI limitation and can be worked around by using Graph API. I’ll show how to do this in my next post. But for now, for simplicity, I’ll use portal UI.
    8
  • Search for the group you want to assign to the role. For now use the group we created above. Select the group from the grid and click Assign from bottom menu. Choose the role and complete the process.
    1314
  • We are done with infrastructure changes. Most of these are one time things and going forward we just have to change assignments based on requirements.

Final changes to web app and test

  • In your OWIN Auth configuration, add following code snippet to tell ASP.NET pipeline to use role claim for Authorization
    image
  • Modify controllers to use Authorize attribute and IsInRole() as required.
    image
  • We are done. We successfully offloaded our authorization infrastructure to Azure AD.
  • Inspect the claims by logging in with the user who is member of group assigned to role as well as the user who is not a member of that group.

Caution & other important stuff

  • User should be direct member of the group which is assigned to the role. If a user is member of inner group, claims will not contain relevant roles.
  • Apart of groups, users can also be assigned to the roles.
  • Current portal UI only supports assigning a group to only one role. What if you want a group to have multiple roles? For example, our group can be used for both approvers and administrators. Good thing is, this is just a portal UI limitation and we can easily do this via Graph API. I’ll add a sample in my next post.
  • As I told earlier, groups can only be assigned to roles from portal UI if you have premium subscription. Again this is just portal UI limitation and can be easily done via Graph API. I’ll add a sample in my next post.

That is it. I think it is pretty simple and powerful way to offload authorization infrastructure of your application.

References:

  1. https://www.simple-talk.com/cloud/security-and-compliance/azure-active-directory-part-4-group-claims/
  2. http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/