【Lightweight Identity Management System 轻量级用户体系设计方案】

LIMS Design Notebook

【Section 1】Application ARCHITECTURE

LEVEL 1: Monolithic Architecture

• Codes are developed and maintained within a single application.

LEVEL 2: Vertical Architecture

• Tiered application. Mostly use the MVC mode (a 3-tier simple architecture mode).
• Key Words: Veritically Tiered, Load Balancing.

LEVEL 3: SOA Architecture

• Build the cloud computing ecology for an enterprise. Services are provided to the other components by distributed and reusable application components.
• Service behaviors are predictable.
• Services are defined by platform-neutral interface contract.
• Key Words: RPC, Frontend and Backend Split, Caching, Middleware, Full-Text-Search.

LEVEL 4: Microservice Architecture (MSA)

• System consists of a group of microservices in separate processes. Communication between microservices uses HTTP resource APIs (lightweight).
• Key Words: Split Business and Database, Service Governance and Monitoring, Distributed Caching.

Architecture Consistency

• Meet requirements in Open-Source, Internal Ecology, Business scenarios.

【Section 2】QUICK START

FUNCTIONALITY

1. USER & GROUP MANAGEMENT
2. SIGN IN & SIGN ON
3. ACCESS CONTROL
4. AUTHORIZATION
5. ACCESS MANAGEMENT

【Section 3】SSO MANAGEMENT

Enable / Disable SSO

Create Resource Directory

Modify Resource Directory

Associate SSO with Authorization

【Section 4】USER MANAGEMENT

1. Basic Support

1. Create
2. Show
3. Modify
4. Enable / Disable

2. Sign In Settings

• Only ONE of the following options is available at the same time.

1. Username / Password
2. SSO

3. 2FA/MFA Management

1. Enable / Disable
2. Delete 2FA/MFA Device

【Section 5】ORGANIZATION MANAGEMENT

1. Basic Support

1. Create
2. Show
3. Modify
4. Add / Remove User(s)

【Section 6】EXTERNAL IDENTITY MANAGEMENT

1. SCIM (System for Cross-Domain Identity Management) Synchronization

1. Goal: Standard Multi-Tentant Cloud Application / Service Identity Management
2. Requirement: To synchronize users / groups from the enterprise IdP.
3. Steps

• Create SCIM key; Enable SCIM Synchronization from the console.
• Add / Remove User(s) / Group(s) to / from the application.
• Set up the Enterprise IdP Synchronization in the application.
• Verification: Sign in the system console. View the list of users / groups that has the successful synchronization (source is marked as ‘SCIM Synchronization’).

4. Keys Management

• Each account has at most a limit number of SCIM keys.
• Operations: Create, Enable / Disable, Delete.

5. Enable / Disable SCIM Synchronization
6. SCIM 2.0 Object Model

• All objects MUST be inherited from the Resource.
• Official Models: Resource, User, Group, Enterpriseuser

7. Scenarios
   1. Identity Migration from one Cloud Provider to the other
      • apply SCIM on all stakeholders, i.e., User and Cloud Provider(s)
   2. SSO between trusted applications running in different Cloud Providers
   3. Identity Management: SaaS for a Global Commity
      • Identity Settings
      • Dispatch Info
   4. User Attributes Transferred between Trusted Websites based on Authorization Protocol (OAuth, SAML, etc)
   5. Change Notifications to Website, Requests for change(s) update (caches) issued at desired time to Directory
8. Features: Interactive, Secure, Scalable; Easy, Cost-Efficient.

2. SSO (Single-Sign-On)

1. Workflow

• In the view of the IdP: Set up the system as the trusted SAML SP.
• In the view of the system: Set up the IdP as the trusted SAML IdP.
• Enable SCIM Synchronization.
  • Big volume of data: synchronoize to the system.
  • General volume of data: Register from the system.
• Enterprise IdP user SSO.

【Section 7】ACCESS CONTROL

1. Overview

2. Create

3. Modity

4. Authorization Management

1. Goals: abstract, plug-in, compatible.
2. Internal Systems: RBAC

• Define the account authorization record by a set of roles.
• Formula: Account + Role + Permission

3. External Systems: ABAC

• Define the account authorization record by a set of policies.
• Formula: Account + Policy + Rule

4. Note: The more fine the authorization granularity is, the bigger the data volume is.

5. Client Access Types

1. Confidential

• Design for Server-Side Application
• Sign in by Browser
• Retrieve Access Token by keys
• Scenario: Web Application rendered by server

2. Public

• Design for Client-Side Application
• Sign in by Browser
• Scenario: Frontend Web Application

3. Token

• Design for Server-Side Application
• Scenario: RESTful API

【Section 8】AUTHORIZATION MANAGEMENT

1. Manage Multi-Account Authorization

2. Resource Account Authorization

3. Deployment of Access Configurations

【Section 9】SIGN IN MANAGEMENT

1. Sign In from The Portal, and Access Resources

2. Sign In by CLI, and Access Resources

【Section 10】BEST PRACTICES

1. API Calling

2. Common Parameters

3. Service Management

【Section 11】SSO References

Popular B/S-Architecture SSO Protocols

1. CAS 3.0

• Goal: Authentication
• Response Type: Ticket

2. OAuth 2.0

• Goal: Authorization
• Response Type: Access Token, Refresh Token
• Pros: Easy to apply; Community support.
• Cons: Different implements that need customized development; ONLY Authorization.

3. OIDC (OpenID Connect) 1.0

• Goal: Authorization + Authentication
• Response Type: ID Token, Access Token, Refresh Token
• Pros: Easy to apply; Community support; Authorization + Authentication; Support mobile application and SPA application.
• Cons: Calls from Client to OpenID Provider may fail due to network failure.

4. SAML 2.0

• Goal: Authentication
• Response Type: XML Assertion
• Pros: Complete support for various SSO scenarios.
• Cons: Heavy to apply (too many optional details); Technical complexity for signature and encryption based on XML.