MOSIP Docs 1.1.5
GitHubCommunityTech Blogs
  • Home
  • Architecture
    • Guiding Principles
    • MOSIP Architecture
      • Technology Stack
    • MOSIP and Data
      • Naming Standards
      • Data-Model
    • Privacy & Security
      • Cryptography in MOSIP
    • Anonymous Profiling Support
  • Modules
    • Pre-Registration
      • Pre-Registration Functionality
      • UI Specification for Pre-registration
      • Pre-Registration Configuration
    • Registration
      • Registration Functionality
      • Registration Packet
      • Registration Client Setup
      • First User Registration and Onboarding
      • Guide to Configure MOSIP for Biometrics
      • Guide to On-board Biometric Devices
      • Device Integration Specifications
      • UI Specification for Registration Client
    • Registration Processor
      • Registration Processor Functionality
      • Deduplication and Manual Adjudication
      • MOSIP ID Object Definition
    • ID Repository
    • ID Authentication
      • ID Authentication Functionality
    • Resident Services
      • Resident Services Functionality
    • Partner Management
      • Partner Management Functionality
      • MOSIP Partner Secure Communication
      • Partner Self Service Portal
    • Administration
      • Admin Services Functionality
      • Download Card
    • Kernel
      • Audit Manager Functionality
        • Admin Service Audits
        • Resident Service Audits
        • Partner Management Audits
        • Registration Client Audits
        • Registration Processor Audits
        • ID Repository Audits
        • ID Authentication Audits
        • Pre-registration Audits
      • Authentication and Authorization Functionality
      • Auth Adapter
      • Auth Implementation
      • Common Services Functionality
      • Data Services Functionality
      • Master Data Services Functionality
      • UIN and VID Generation Service Functionality
      • VID Generator
  • Biometrics
    • ABIS
    • Biometric SDK
    • MDS Specification
    • Biometric Specification
    • CBEFF XML
    • Compliance Tool Kit
  • Build & Deploy
    • Sandbox Installer
    • Deployment Architectures
    • Cell Based Deployment Architecture
    • Hardware Security Module HSM Specifications
    • Hardware Sizing
    • Customizations for a Country
    • Other Installation Guides
      • Steps to Install and Configure HDFS
      • Steps to Install and use PostgreSQL Version 10.2 on RHEL 7.5
      • Steps to Install Clam AntiVirus Version 0.101.0
      • Steps to Install Keycloak Standalone Server
    • Services in MOSIP
  • Glossary
  • Contribute
    • Call for Contribution
    • Contributor's Guide
    • Code of Conduct
    • Issue Reporting Guideline
    • Coding Standards
      • Auth Angular User Guide
      • Auth SpringBoot User Guide
      • Gitub Workflow
      • MOSIP Java Coding Standards
      • MOSIP REST API guidelines
      • Registration Client UI Developer Document
      • Registration Client Developer Documentation
      • Security Tools
    • Testing
      • Test Rig Design
      • Tester Documentation
      • Testing Attachments Kernel
  • APIs
    • ABIS APIs
    • Admin APIs
    • AuthN and AuthZ APIs
    • Biometric SDK APIs
    • BlacklistedWords APIs
    • Common APIs
    • Device APIs
    • Device Type and Subtype APIs
    • Device Management APIs
    • Document APIs
    • Dynamic Fields APIs
    • Holiday APIs
    • ID Authentication APIs
    • ID Repository APIs
    • ID Schema APIs
    • Kernel APIs
    • Machine APIs
    • Master Data Biometric APIs
    • Packet APIs
    • Packet Manager APIs
    • Partner Management Service APIs
    • Pre Registration APIs
    • Registration Center APIs
    • Registration Processor APIs
    • Resident Service APIs
    • Sync Data APIs
    • Template APIs
    • Zone APIs
  • Older Releases
    • Release Notes 1.1.5
      • Enhancements
      • Defect Fixes
      • Patches
        • Patch 1.1.5.5
        • Patch 1.1.5.5-P1
    • Release Notes 1.1.4
      • Enhancements
      • Defect Fixes
    • Release Notes 1.1.3
      • Features
      • Bug Fixes
    • Release Notes 1.1.2
      • Features
      • Bug Fixes
    • Release Notes 1.1.1
      • Bug Fixes
      • Artifact Version
    • Release Notes 1.1.0
      • Features
      • Bug Fixes
      • 1.2.0 Features
      • Artifact Version
    • Release Notes 1.0.6
    • Release Notes 1.0.5
    • Release Notes 1.0.0
      • Features
    • Release Notes 0.9.0
  • Roadmap
    • Roadmap Activities
  • Revision History
  • License
Powered by GitBook
On this page
  • Authentication flow:
  • Authorization flow:
  • Implementation of above flows:
  • Http Interceptor
  • Roles Directive

Was this helpful?

Export as PDF
  1. Contribute
  2. Coding Standards

Auth Angular User Guide

Guidelines to implement Authorization and Authentication techniques in the Angular application are detailed in this document.

Before going in to the components let us discuss the following flows of Authorization and Authentication.

Authentication flow:

  1. Initially a login request is made passing user credentials to a REST API as specified in the SPECS of that API.

  2. In the response of a successful authentication you will receive user details and an auth_token as the value of the header "Authorization".

  3. Now the received auth token has to be stored and re-used. For example let us use sessionStorage to store the auth_token under the key "TOKEN".

  4. Now any kind of HTTP/HTTPS requests we make from the application has to be sent by adding a header "Authorization" and value of auth_token stored in sessionStorage with key by name "Token" for the purpose of authentication.

  5. If the response comes back with a new token which might be because of previous token getting expired or refresh token mechanisms that happen in the backend, we need to replace the old token with the new one in the session storage.

Authorization flow:

  1. After successful login the user details are sent to the client(Angular application/ Browser).

  2. Now store the userDetails in the sessionStorage for example under the key "UserDetails".

  3. Now we need to hide some pages/components/user action elements etc. based on the roles that the user possess.

Implementation of above flows:

To implement the Authentication and Authorization flows mentioned above, all we need to do is implement an Interceptor and a Directive which were mentioned above and detailed below.

Http Interceptor

Tasks to be implemented in a Client/UI Http interceptor are:

  1. Append "Authorization" header to the request using the token value stored in the session storage.

  2. Replace/Add the session storage token value with the one received in the response "Authorization" headers.

Below code implements the requirements mentioned above:

import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpResponse, HttpEvent, HttpEventType } from '@angular/common/http';
import { Observable } from 'rxjs';
import { map, catchError, tap } from 'rxjs/operators';

@Injectable({
  providedIn: 'root'
})

export class InterceptService implements HttpInterceptor {
  constructor() { }

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const token = sessionStorage.getItem('TOKEN');
    if (token) {
      request = request.clone({
        setHeaders: {
          'Authorization': token
        }
      });
    }

    return next.handle(request).pipe(tap(event => {
      if (event instanceof HttpResponse) {
        const receivedToken = event.headers.get('Authorization');
        if (receivedToken) {
          sessionStorage.setItem('TOKEN', receivedToken);
        }
      }
    }, err => {
      console.log(err);
    }));
  }
}

Roles Directive

Role of the Roles directive is to fetch roles from UserDetails stored in the session storage and verify if the user has required roles to perform some action or read some details and restrict access accordingly.

Below code implements the requirements mentioned above:

import { Directive, TemplateRef, ViewContainerRef, Input, ElementRef } from '@angular/core';

@Directive({
  selector: '[appRole]'
})

export class RoleDirective {
  userRolesString: any;
  userRoles: Array<string>;
  shouldDisplay = false;
  requiredRoles: Array<string>;

  constructor(private element: ElementRef) { }

  @Input() set appRole(roles: string) {
    this.element.nativeElement.hidden = true;
    const userSessionData = sessionStorage.getItem('UserDetails');
    this.userRolesString = JSON.parse(userSessionData).role;
    this.userRoles = this.userRolesString.split(',');
    this.requiredRoles = roles.split(',');
    this.shouldDisplay = this.userRoles.some(v => this.requiredRoles.indexOf(v) !== -1);
    if (this.shouldDisplay) {
      this.element.nativeElement.hidden = false;
    }
  }
}

Now inject the above interceptor and directive in the app.module.ts as follows

@NgModule({
  declarations: [ RoleDirective, ...],
  imports: [...],
  providers: [{
    provide: HTTP_INTERCEPTORS,
    useClass: InterceptService,
    multi: true
  }, ...],
  bootstrap: [AppComponent]
})

To activate/deactivate => show/hide element all we need to do is add the appRole attribute to the HTML element as shown below:

<button class="btn btn-success" appRole="DIVISION_ADMIN,SUPERVISOR">Add</button>

In the above sample, the add button will only be visible for users with DIVISION_ADMIN or SUPERVISOR role.

Note: Above mentioned code snippets are not the final implementations. Based on the API specs and a few other factors the method implementations might change a bit. However, the component structures remain the same.

PreviousCoding StandardsNextAuth SpringBoot User Guide

Last updated 8 months ago

Was this helpful?