标签：Management Section System Access SSO Authorization 轻量级 Architecture

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

• LIMS Design Notebook
• • 【Section 1】Application ARCHITECTURE
  • • LEVEL 1: Monolithic Architecture
    • LEVEL 2: Vertical Architecture
    • LEVEL 3: SOA Architecture
    • LEVEL 4: Microservice Architecture (MSA)
    • Architecture Consistency
  • 【Section 2】QUICK START
  • • FUNCTIONALITY
  • 【Section 3】SSO MANAGEMENT
  • • Enable / Disable SSO
    • Create Resource Directory
    • Modify Resource Directory
    • Associate SSO with Authorization
  • 【Section 4】USER MANAGEMENT
  • • 1. Basic Support
    • 2. Sign In Settings
    • 3. 2FA/MFA Management
  • 【Section 5】ORGANIZATION MANAGEMENT
  • • 1. Basic Support
  • 【Section 6】EXTERNAL IDENTITY MANAGEMENT
  • • 1. SCIM (System for Cross-Domain Identity Management) Synchronization
    • 2. SSO (Single-Sign-On)
  • 【Section 7】ACCESS CONTROL
  • • 1. Overview
    • 2. Create
    • 3. Modity
    • 4. Authorization Management
    • 5. Client Access Types
  • 【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
      • 2. OAuth 2.0
      • 3. OIDC (OpenID Connect) 1.0
      • 4. SAML 2.0

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.

标签：Management,Section,System,Access,SSO,Authorization,轻量级,Architecture
来源： https://blog.csdn.net/weixin_55413092/article/details/122307539

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。