精华内容
下载资源
问答
  • 单点登录 统一用户管理
    千次阅读
    2019-06-07 21:25:00

    单点登录(Single Sign- On,简称 SSO)是指用户成功登录某个业务系统之后,就可以以一定的权限直接访问其他受信任的业务系统,无需再输入用户名和密码等认证信息,大大方便了用户使用各类业务系统。
    SSO的实现技术点包括所有业务系统共享一个身份认证系统和所有应用系统能够识别和提取 ticket 信息。目前主要有三种较为成熟的单点登录解决方案:基于 Passport 协议的单点登录方案、基于 SAML 协议的单点登录方案、基于 CAS协议的单点登录方案。
    微软 Passport 是由微软公司运行的一种 Web 服务,该服务会使用户登录到网站以及执行电子商务交易的过程变得更加简便。微软的 Passport 服务是.Net战略的一部分,通过一次登录就可以使用户获得访问很多网站的权限。

    SAML(Security Assertion Markup Language)是安全
    断言标记语言。SAML 是一个 XML 框架,由一组协议

    用来传输安全声明。SAML获得了广泛的行业认可,并被诸多主流厂商所支持。SAML 2.0 规范说明书主要包含以下四方面内容,
    (1)SAML Assertions 断言:定义交互的数据格式(XML)。
    (2)SAMLProtocols协议:定义交互的消息格式 (XML、processingrules)。
    (3)SAMLBindings 绑定:定义如何与常见的通信协议绑定(HTTP、SOAP)。
    (4)SAML Profile 使用框架:给出对SAML 断言及协议如何使用的建议 (Protocols、Bind-ings)。需要注意的是,SAML并没有提供完整的单点登
    录解决方案,它只是提供了描述安全信息的标准框架和交换安全信息的协议

    CAS 是 Central Authentication Server 的缩写,中央认证服务,一种独立开放指令协议。CAS 是 Yale 大学发起的一个开源项目,旨在为 Web 应用系统提供一种
    可靠的单点登录方法,CAS 在 2004 年 12 月正式成为JA- SIG的一个项目。CAS具有以下特点:
    (1)开源的企业级单点登录解决方案
    (2)CASServer 是需要独立部署的 Web 应用。
    (3)CAS Client 支持非常多的客户端
    (这里指单点登录系统中的各个 Web 应用),包括 Perl,Java, .Net, uPortal, Apache, Ruby, PHP 等

    转载于:https://www.cnblogs.com/zyt-bg/p/10989230.html

    更多相关内容
  • 一、背景和目的 解决如下问题: ... 具备用户的基本信息、角色、资源权限等集中管理和控制。 提供统一的集中办公Portal门户网站,在里面无缝链接其他系统的页面和功能。 关键术语: ...

     

    一、背景和目的

     

    解决如下问题:

    1. 打通所有系统的账户密码,只需要记住一个就行,而且登录一个系统后,打开其他系统不需要再登录。

    2. 不需要记住多个系统的地址,甚至不需要在多个系统页面跳来跳去,通过一个门户网站,串通起常用功能。

    需求如下:

    1. 具备单点登录功能,并且能为第三方应用提供主流的登录认证。

    2. 具备用户的基本信息、角色、资源权限等集中管理和控制。

    3. 提供统一的集中办公Portal门户网站,在里面无缝链接其他系统的页面和功能。

     

    关键术语:

        IAM(Identity and Access Management),即“身份识别与访问管理”,具有单点登录、强大的认证管理、基于策略的集中式授权和审计、动态授权、企业可管理性等功能。

     

    本文涉及关键词:

        IAM, SSO, CAS, OpenID, OICD, OAUTH, SAML, Keycloak, LDAP, RSA, RBAC, MFA等。

        如果这些关键词你都熟悉,就不用继续看了。

     

    一、相关技术研究

     

    1、单点登录

     

    用户仅需要在门户系统登录一次,就可以获得授权范围内所有企业应用程序的访问权,用户只需要记住一个帐号即可。

     

    1)门户认证中心

        利用门户系统建立统一的 SSO 认证中心,通过 SSO 中心认证后,应用系统利用 SSO API 同 Portal Server 通信,验证用户是否经过认证。新开发的应用系统大多使用这种 SSO 的实现方式。这种方式需要对应用系统的认证模块进行修改。

     

    2)单点登录的实现方式非常非常多,此处仅举一例(后面会详细讨论) 

        LTPA:Lightweight Third-Party Authentication 是IBM Websphere和Domino产品中使用单点登录技术。当服务器配置好LTPA认证方式,用户通过浏览器成功登录后,服务器会自动发送一个session cookie给浏览器;此cookie中包含一个LTPA Token。

        参与SSO的系统必须在同一个DNS域下面(因为浏览器cookie共享的限制,跨域不能共享cookie)。

        参考文档:

    https://wenku.baidu.com/view/c8cc8a5da58da0116d17496f.html

    https://www.cnblogs.com/hannover/archive/2011/05/29/2061798.html

     

    2、伪单点登陆

     

        通过 统一Portal认证后,应用系统还要自己进行用户的认证。这种方式适用于那些无法修改认证模块的应用系统。这种情况可以利用应用系统比较基础的接口来实现,如 URL+User+Password、Form 表单代填等。主要有以下几种技术选择:

     

    1)基于 Form 方式

        这种方式是通过模拟用户凭证提交,将业务系统相关的用户凭证通过 Form 提交的方式,传递给业务系统认证模块。

    这种方式适合待集成的业务系统认证方式采用 From 表单,当通过 portlet 技术封装 Form 表单包含有业务系统相关的用户凭证,以及资源 URL。通过将业务系统所需的用户凭证通过 Form(表单)提交方式,模拟用户登陆,业务系统将用户所需的资源通过 web 方式反馈用户。

     

    点评:不靠谱,由于安全性限制,“Form 表单代填”在浏览器上几乎无法实现。

     

    2)URL

        将用户凭证直接通过 URL 的方式发送给业务系统,业务系统的认证程序将截获的用户请求 URL 中获取用户凭证,从而实现门户与业务系统的单点登陆。或者将用户凭证存储在 HTTP 请求报头,业务系统认证程序通过解析 HTTP 请求头信息,获取用户凭证。

     

    点评:要求不高的情况下,可以采用这种方法。

     

    3)模拟证书

        实现单点登陆的业务系统用户认证方式并不是基于 Form,也不是采用 HTTP Header。需要客户端(此是门户信息系统将被作为客户端,业务系统将作为服务器)提供客户电子证书,这需要通过 portlet 应用程序,或 J2EE 应用程序来实现模拟将电子证书发送给业务系统认证模块。

     

    3、整合第三方软件的单点登陆

     

    使用信任关联拦截器(TAI)的第三方认证。如 Tivoli Access Manager,CA SiteMinder 等。门户通过使用第三方认证服务器作为外部安全管理器单点登陆。通过定义访问控制规则,由第三方认证服务器来实现用户登陆业务系统的认证功能,将大大简化集成带来的烦琐工作。

     

    通常第三方认证服务器(如 Tivoli Access Manager、WebSeal 或者 CA SiteMinder)会提供默认的验证机制采用内置共享库的形式支持通过用户名和密码客户方证书 RSA SecurID 令牌或 HTTP header( 报头 )。选择性将会更多,便于用户根据实际软件需求配置所需的方式。

     

    认证方式包括

    • Forms-based login

    • HTTP basic authentication

    • Digital Certificate (X.509v3)

    • RSA SecurID Token

    • WAP identity mechanism

    • Resource-sensitive authentication

    • Kerborse

    还可以支持 Credentials Acquisition Service (CAS),从而实现外挂的用户认证方式,如:

    • 数据库的认证方式,如 Oracle,DB/2

    • 其它 security tokens (Vasco DigiPass)

    • 用户定义的认证方式,如使用用户访问代码 PIN 和 Code

    • RADIUS

    • Biometrics

     

    综上,总结如下:

        最主流的还是 单点登录,但是单点登录的协议、形式、平台多种多样(后文会重点分析)。

        一般不考虑 伪单点登录,因为安全性太低。

     

    4、页面前端集成展现(基于页面内容的集成)

    iFrame Portlet

    基于页面的集成整合可以通过 iFrame Portlet 的方式,这也是门户项目中常见的一种集成方式。

     

    通过 iFrame Portlet 集成依赖于以下几种情况:

     

    1)此方法只适合 B/S 的业务应用系统。

    此种集成方式的前提是:门户系统和应用系统之间已经实现 SSO。由于应用系统的页面之间在门户页面中展现,故需要考虑 SSO 的自动实现。

    实现方式:在用户登陆门户站点时,将登陆门户的业务系统账号统一保存在用户会话中。并且实现应用系统的认证环节,当通过 iFrame 方式实现页面集成时,通过将业务系统的用户凭证从用户会话提取,然后直接通过配置的 URL 展现即可。

     

    2)需要应用系统提供具体的,可配置的 URL。

    可选,为了更好的适应集成的需要,可能需要更改业务系统 URL 级接口或者修改认证模块。例如:业务系统修改认证模块,来满足集成的要求 ; 业务系统修改功能模块加入 URL 认证能力。

     

    3)业务系统界面需满足 VI 设计要求

    为保证门户站点的整体风格,业务系统的展示页面将必须满足门户站点的 VI 设计要求。

     

    另外,有非常非常低的几率会遇到页面的问题:

    • 使用 Iframe 框架,可能会改变原有应用的 HTML 结构,导致某些脚本无法运行。

    • 在一个页面中过多的嵌入 IFrame,由于不同 浏览器版本对于 IFrame 的处理能力各异,可能会出现不可预料的异常效果。

     

    总结:

        如果非要做页面集成展现的话,

    • 1)只有iframe是最通用、简单的办法了。除此之外,还有如下两个笨办法:

    • 2)集中部署,把相关项目合并,部署在同一个war包中,这种方式我曾经做过,但是问题很多,例如上线问题;

    • 3)各项目提供API,然后把页面代码 单独放在一个项目中,这种方式对大型项目不实用,开发工作量太大,只适合小功能小需求。

     

       总之,我个人并不建议做大规模的页面集成,用单点登录,能统一访问到各个平台就行了,没必要把各个平台的页面集成到同一个视图中,这样用户体验反而不好,特殊需求,可以按(3)的办法做集成,提供一个统一管理平台就行了。

     

    5、SSO单点登录涉及的基本对象

    应用/模块/对象说明
    前台站点需要登录的站点
    SSO站点-登录提供登录的页面
    SSO站点-登出提供注销登录的入口
    SSO服务-登录提供登录服务
    SSO服务-登录状态提供登录状态校验/登录信息查询的服务
    SSO服务-登出提供用户注销登录的服务
    数据库存储用户账户信息
    缓存存储用户的登录信息,通常使用Redis

     

    参考资料:https://ken.io/note/sso-design-implement

     

    6、OIDC (OpenID Connect) 和 SAML (The Security Assertion Markup Language)

    (可以直接看我的中文翻译)

    1)What is OpenID Connect? How does it work?

        OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message.(一个基于OAuth2.0的认证协议,使用REST/JSON消息)

        OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.(支持各种客户端,包括Web应用、手机APP等)

     

    2)What is OAuth 2.0 and how does it related to OpenID Connect?

        OAuth 2.0, is a framework, specified by the IETF in RFCs 6749 and 6750 (published in 2012) designed to support the development of authentication and authorization protocols. It provides a variety of standardized message flows based on JSON and HTTP; OpenID Connect uses these to provide Identity services.(OAuth2是一个授权协议,它无法提供完善的身份认证功能,而OIDC使用OAuth2的授权服务器来为第三方客户端提供用户的身份认证,并可以适用于各种类型的客户端(比如服务端应用,移动APP,JS应用),且完全兼容OAuth2,也就是说你搭建了一个OIDC的服务后,也可以当作一个OAuth2的服务来用)

     

    3)Does OpenID Connect work for native and mobile apps?

        Yes. There are already system-level APIs built into the Android operating system to provide OpenID Connect services. OpenID Connect can also accessed by interacting with the built-in system browser on mobile and desktop platforms; a variety of libraries are under construction to simplify this process.(OpenID Connect得到了Google Android操作系统的原生支持)

     

    4)How does OpenID Connect relate to SAML?

        The Security Assertion Markup Language (SAML) is an XML-based federation technology used in some enterprise and academic use cases. OpenID Connect can satisfy these same use cases but with a simpler, JSON/REST based protocol. OpenID Connect was designed to also support native apps and mobile applications, whereas SAML was designed only for Web-based applications. SAML and OpenID Connect will likely coexist for quite some time, with each being deployed in situations where they make sense.

        (两者的基本功能一样,SAML是一个老牌的认证技术,应用比较广泛,比如WindowsServer就自带了这个功能,它基于XML格式的数据。OIDC是后起之秀,也被一些大公司使用,比如Google的账号认证授权体系,基于REST/JSON通信,而且对手机App支持较好)

     

    5)OIDC 核心概念

        OpenID Connect是2014年初发布的开放标准,定义了一种基于OAuth2的可互操作的方式来来提供用户身份认证。

        OAuth2提供了Access Token来解决授权第三方客户端访问受保护资源的问题;OIDC在这个基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题。它还使用JOSN签名和加密规范,用来在传递携带签名和加密的信息。

        OIDC的核心在于在OAuth2的授权流程中,一并提供用户的身份认证信息(ID Token)给到第三方客户端,ID Token使用JWT格式来包装,得益于JWT(JSON Web Token)的自包含性,紧凑性以及防篡改机制,使得ID Token可以安全的传递给第三方客户端程序并且容易被验证。此外还提供了UserInfo的接口,用户获取用户的更完整的信息。

     

    6)ID Tokens

        OpenID Connect Id Token是一个签名的JSON Web Token(JWT:RFC7519),它和OAuth access token一起提供给Client应用程序。Id Token包含一组关于身份认证会话的声明(claim),包括用户的标识(sub)、颁发令牌的提供程序的标识符(iss)、以及创建此标识的Client的标识符(aud)。此外,Id Token还包含token的有效生存期(通常非常短)以及其他相关的上下文信息。由于Client知道Id Token的格式,因此它能直接分析出token的内容而无需依赖外部服务。此外,OpenId Connect还颁发access token给Client,允许Client保持对token的不透明,因为这是属于OAuth规范的一部分。最后,token本身是由提供程序的私钥进行签名的,除了在获取token中受TLS的保护之外,还添加了一个额外的保护层,以防止类似的模拟攻击。通过对此token的一些校验检查,Client可以保护自己免受大量常见的攻击。

        由于Id token是授权服务器签名的,它还提供了在authorization code(c_hash)和access token(at_hash)上添加分离签名的位置,这些hash可以由Client来验证,同时仍保留authorization code和access token对Client不透明的语义,从而防止这一类的注入攻击。

        应该指出的是,Client不再需要使用access token,因为Id token已经包含了处理身份认证所需的所有信息。然而,为了保持和OAuth的兼容性,OpenId Connect会同时提供Id token和acces token。

     

    7)UserInfo Endpoint

        除了Id token包含的信息之外,还定义了一个包含当前用户信息的标准的受保护的资源。如上所述,这些信息不是身份认证的一部分,而是提供附加的标识信息。比如说应用程序提示说“早上好:Jane Doe”,总比说“早上好:9XE3-JI34-00132A”要友好的多。它提供了一组标准化的属性:比如profile、email、phone和address。OpenId Connect定义了一个特殊的openid scope,可以通过access token来开启Id token的颁发以及对UserInfo Endpoint的访问。它可以和其他scope一起使用而不发生冲突。这允许OpenId Connect和OAuth平滑的共存。

     

    8)动态服务发现以及客户端注册

        OAuth2为了允许各种不同的部署而编写,但是这样的设计并没有指定这些部署如何设置以及组件之间如何互相了解,在OAuth自己的世界中这是没问题的。在使用OpenId Connect时,一个通用的受保护的API部署在各种各样的Client和提供者中,所有这些都需要彼此互相了解才能运行。对于每个Client来说,不可能事先了解有关每个提供程序,并且要求每个提供者了解每个潜在的Client,这将大大削弱扩展性。

        为了抵消这种情况,OpenId Connect定义了一个发现协议,它允许Client轻松的获取有关如何和特定的身份认证提供者进行交互的信息。在另一方面,还定义了一个Client注册协议,允许Client引入新的身份提供程序(identity providers)。通过这两种机制和一个通用的身份API,OpenId Connect可以运行在互联网规模上运行良好,在那里没有任何一方事先知道对方的存在。

     

    9)OIDC 主要术语

    主要的术语以及概念介绍(完整术语参见http://openid.net/specs/openid-connect-core-1_0.html#Terminology):

    • EU:End User:一个人类用户。

    • RP:Relying Party ,用来代指OAuth2中的受信任的客户端,身份认证和授权信息的消费方;

    • OP:OpenID Provider,有能力提供EU认证的服务(比如OAuth2中的授权服务),用来为RP提供EU的身份认证信息;

    • ID Token:JWT格式的数据,包含EU身份认证的信息。

    • UserInfo Endpoint:用户信息接口(受OAuth2保护),当RP使用Access Token访问时,返回授权用户的信息,此接口必须使用HTTPS。

     

    参见:http://www.cnblogs.com/linianhui/p/openid-connect-core.html

    https://openid.net/connect/faq/

    https://help.aliyun.com/document_detail/93698.html

     

    10)相关技术

    参见: OAuth 2.0 Core and ExtensionsOpenID Connect 1.0, and Javascript Object Signing and Encryption (JWT-JOSE)

     

    11)SAML 联合登录的基本思路(以阿里云为例)

        阿里云与外部企业身份系统的集成场景中,阿里云是服务提供商(SP),而企业自有的身份服务则是身份提供商(IdP)。企业员工通过企业自有身份服务登录到阿里云控制台的基本流程如下,

        当管理员在完成 SAML 联合登录的配置后,企业员工可以通过如图所示的方法登录到阿里云控制台:

    1. 企业员工 Alice 使用浏览器登录阿里云,阿里云将 SAML 认证请求返回给浏览器。

    2. 浏览器向企业 IdP 转发 SAML 认证请求。

    3. 企业 IdP 提示企业用户登录,并且在用户登录成功后生成 SAML 响应返回给浏览器。

    4. 浏览器将 SAML 响应转发给阿里云。

    5. 阿里云通过 SAML 互信配置,验证 SAML 响应的数字签名以验证 SAML 断言的真伪,并通过 SAML 断言的用户名称,匹配到对应云账号中的 RAM 用户身份。

    6. 登录服务完成认证,阿里云向浏览器返回登录 session 以及阿里云控制台的 URL。

    7. 浏览器重定向到阿里云管理控制台。

    说明 在第 1 步中,企业员工从阿里云发起登录并不是必须的。企业员工也可以在企业自有 IdP 的登录页直接点击登录到阿里云的链接,向企业 IdP 发出登录到阿里云的 SAML 认证请求。

    参见:https://help.aliyun.com/document_detail/93684.html?spm=a2c4g.11186623.6.569.5a6f5cedf4m43L

    https://help.aliyun.com/document_detail/93686.html?spm=a2c4g.11186623.6.572.133e1bb7pRcnRC

     

    7、CAS(Central Authentication Service,中央认证服务)

    CAS是一种独立开放指令协议。CAS 是 Yale 大学发起的一个开源项目,旨在为 Web 应用系统提供一种可靠的单点登录方法。

    The following features are supported by the CAS project:

    • CAS v1, v2 and v3 Protocol

    • SAML v1 and v2 Protocol

    • OAuth v2 Protocol

    • OpenID & OpenID Connect Protocol

    • WS-Federation Passive Requestor Protocol

    • Authentication via JAAS, LDAP, RDBMS, X.509, Radius, SPNEGO, JWT, Remote, Apache Cassandra, Trusted, BASIC, Apache Shiro, MongoDb, Pac4J and more.

    • Delegated authentication to WS-FED, Facebook, Twitter, SAML IdP, OpenID, OpenID Connect, CAS and more.

    • Authorization via ABAC, Time/Date, REST, Internet2's Grouper and more.

    • HA clustered deployments via Hazelcast, Ehcache, JPA, Apache Cassandra, Memcached, Apache Ignite, MongoDb, Redis, DynamoDb, Couchbase and more.

    • Application registration backed by JSON, LDAP, YAML, Apache Cassandra, JPA, Couchbase, MongoDb, DynamoDb, Redis and more.

    • Multifactor authentication via Duo Security, YubiKey, RSA, Google Authenticator and more.

    • Administrative UIs to manage logging, monitoring, statistics, configuration, client registration and more.

    • Global and per-application user interface theme and branding.

    • Password management and password policy enforcement.

    The foundations of CAS are built upon: Spring Boot and Spring Cloud.

    1552877720297015130.png

    支持的平台如下:

     

    8、Keycloak

    Keycloak基于OAuth 2.0、Open ID Connect、JSON Web Token(JWT)和SAML 2.0规范,为浏览器应用和RESTful Web Service提供SSO和IDM集成。

    主要功能:

    • Single-Sign On and Single-Sign Out for browser applications.

    • OpenID Connect support.

    • OAuth 2.0 support.

    • SAML support.

    • Identity Brokering - Authenticate with external OpenID Connect or SAML Identity Providers.

    • Social Login - Enable login with Google, GitHub, Facebook, Twitter, and other social networks.

    • User Federation - Sync users from LDAP and Active Directory servers.

    • Kerberos bridge - Automatically authenticate users that are logged-in to a Kerberos server.

    • Admin Console for central management of users, roles, role mappings, clients and configuration.

    • Account Management console that allows users to centrally manage their account.

    • Theme support - Customize all user facing pages to integrate with your applications and branding.

    • Two-factor Authentication - Support for TOTP/HOTP via Google Authenticator or FreeOTP.

    • Login flows - optional user self-registration, recover password, verify email, require password update, etc.

    • Session management - Admins and users themselves can view and manage user sessions.

    • Token mappers - Map user attributes, roles, etc. how you want into tokens and statements.

    • Not-before revocation policies per realm, application and user.

    • CORS support - Client adapters have built-in support for CORS.

    • Service Provider Interfaces (SPI) - A number of SPIs to enable customizing various aspects of the server. Authentication flows, user federation providers, protocol mappers and many more.

    • Client adapters for JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring, etc.

    • Supports any platform/language that has an OpenID Connect Resource Provider library or SAML 2.0 Service Provider library.

     

    • 支持开放ID链接、SAML 2.0 SSO和浏览器社交应用代理的单点登出。无需编写代码,即可提供Google、Facebook、Yahoo、Twitter社交应用登录。

    • 认证代理:可以作为外部SAML 2.0或OIDC代理进行认证。也可以集成LDAP/活动目录。

    • 带有验证码功能的用户注册(可选)

    • (通过Google认证器)提供密码及TOTP功能。用户证书认证即将上线。

    • 为管理员和普通用户提供用户会话管理。

    • 为用户主页提供定制主题:包括登录、授权页面,账户管理、email和管理员终端都可以定制!

    • 为REST服务提供OAuth 2.0 Token认证。

    • 将REST服务Token传递集成到浏览器应用中。

    • 管理员REST API

    • 支持CORS

    • 管理员终端提供了用户管理、角色管理、角色映射、应用程序管理、用户会话、CORS Web源及OAuth客户端支持。

    • 作为独立WAR、设备或Openshift云服务(SaaS)部署。

    • 支持JBoss AS7、EAP 6.x、Wildfly、Tomcat、Jetty和纯Javascript应用程序。计划支持Node.js、RAILS、GRAILS和其它非Java应用程序。

    • 为开发环境、开发平台和编程语言提供无需客户端适配器的HTTP安全代理。

    • 为纯Javascript应用程序提供Javascript/HTML 5适配器。

    • 为管理员终端提供会话管理。

    • 声明/断言映射。让你的Token和断言XML看起来如你所愿。

    • 证书撤销策略。

    • 密码策略。

    • 扮演(Impersonation),管理员可以扮演用户调试问题。

    • 为现代应用程序和服务提供开源认证及访问管理。

     

    Keycloak supports fine-grained authorization policies and is able to combine different access control mechanisms such as:(其授权模型支持如下几种:)

    • Attribute-based access control (ABAC)

    • Role-based access control (RBAC)

    • User-based access control (UBAC)

    • Context-based access control (CBAC)

    • Rule-based access control

    • Using JavaScript

    • Using JBoss Drools

    • Time-based access control

    • Support for custom access control mechanisms (ACMs) through a Policy Provider Service Provider Interface (SPI)

     

    参见:

    https://blog.csdn.net/daqiang012/article/details/80948940

    https://www.cnblogs.com/weschen/p/9530044.html

    https://www.jianshu.com/p/c9b1ecd28813

    https://segmentfault.com/a/1190000018190135?utm_source=tag-newest

    https://www.keycloak.org/docs/latest/securing_apps/index.html#supported-platforms

    https://www.keycloak.org/docs/latest/authorization_services/index.html

     

    8、其他身份验证技术

    SASL(简单身份验证会话层)

    Generic Security Service API (GSSAPI)

    LDAP、Active Directory

    Kerberos(由JBoss开源的)

    Multifactor Authentication (MFA) 多因素认证

    OTP(One-time Password)

    Proxy Authentication

     

    9、资源权限控制模型

    以开源的Casbin项目为例,它支持如下一些权限模型:

    1. ACL (Access Control List)

    2. ACL with superuser

    3. ACL without users: especially useful for systems that don't have authentication or user log-ins.

    4. ACL without resources: some scenarios may target for a type of resources instead of an individual resource by using permissions like write-articleread-log. It doesn't control the access to a specific article or log.

    5. RBAC (Role-Based Access Control)

    6. RBAC with resource roles: both users and resources can have roles (or groups) at the same time.

    7. RBAC with domains/tenants: users can have different role sets for different domains/tenants.

    8. ABAC (Attribute-Based Access Control): syntax sugar like resource.Ownercan be used to get the attribute for a resource.

    9. RESTful: supports paths like /res/*/res/:id and HTTP methods like GETPOSTPUTDELETE.

    10. Deny-override: both allow and deny authorizations are supported, deny overrides the allow.

    11. Priority: the policy rules can be prioritized like firewall rules.

    最常用的是 RBAC 的变种增强模式,当然其他各种模型也有用武之地。

    有了这些模型后,还得定一套资源权限定义的语法及解析工具,这些Casbin都为我们做了。

    参见:https://www.v2ex.com/t/531053

     

    还有一个开源项目 ladon,亚马逊就是用的这个

    https://github.com/ory/ladon

     

    对比分析参见:https://www.v2ex.com/t/536855

     

     

    二、技术选型和对比

     

    1、确定采用哪种身份认证协议、数据源和授权方案(CAS, SAML, OpenID Connect等等) 

     

    首先说 SAML2.0,它是第一个身份认证标准(但不是唯一一个),而且功能非常强大,已经流行了很多年,像Windows Server等都自带了 SAML 2.0的认证。目前阿里云、腾讯云等,都支持 SAML 2.0登录。

    SAML2.0的缺点是

    1)太复杂;

    2)基于XML,对浏览器不太友好;

    3)对移动端APP支持不好;
    4)年事已高,在新系统中用得越来越少。

     

    再说 OpenID Connect,它是后起之秀,起于2014年,目前Google等很多大公司都在使用了。它的优点主要有:

    1)后起之秀,吸取了SAML 2.0等其他标准的优点,功能也非常强大。

    2)基于JSON(JWT),对浏览器友好,且原生支持移动端(Android系统直接内置了);

    缺点是:

    1)还是很复杂……

    2)基于OAuth2.0,对OAuth2.0是强依赖。

     

    再说 CAS,v1/v2/v3,目前最新是v3版本,MIT提出来的,也有很多年历史了,但是它功能弱,主要适用于WebApp,还有就是 主要和 CAS projects绑定在一起使用,在Java应用中比较流行。还有,CAS既是一个协议,也是一套解决方案,CAS Projects已经非常成熟,缺点是非常非常的庞大冗余,后面会详细讲这个问题。

     

    再说 LDAP,它也可以用来做SSO,而且很多系统和软件都支持LDAP登录。但是它只是一个用来认证用户和密码的方法而已,说得更直接一点,你可以把LDAP看做一个存储用户数据的统一的数据库而已,所谓的SSO就是在这个统一的LDAP数据库中去查询用户名和密码,在某些场景,完全可以用MySQL等数据库直接替换掉LDAP。

     

    再说 基于OAuth2.0的身份认证,这种方式 属于 伪身份认证,功能非常弱,不如 OpenID Connect专业,故直接Pass掉。

     

    以上是我的研究结论,一家之言。可以再看看其他人的分析:

    https://www.keycloak.org/docs/latest/securing_apps/index.html#openid-connect-vs-saml

     

    结论如下:

    身份认证协议,最终决定用OpenID Connect

    授权协议,没什么好说的,目前大家都在用 OAuth 2.0,它是最佳选择

     

    PS:差一点我就选CAS了,选CAS无非是看重它的简单和成熟,然而试用了CAS 平台之后,我发现并非如此,故放弃。

     

    崩溃1:学习、分析对比这些协议,让我精神崩溃。来个最简单的——CAS协议,感受一下:

    https://apereo.github.io/cas/development/protocol/CAS-Protocol.html

     

    2、确定采用哪个平台(Apereo CAS、MITREid Connect、KeyCloak等) 

     

    各种协议的平台非常非常多,开源的、商业的,都很多,甚至有Okta这样的专业的,已经发展成独角兽、上市公司的平台。

    这里先排除 商业的平台,这些商业的平台,给人的感觉是,万能的,功能非常强大,几乎所有协议都支持的,然而我只想要一个简单的能完全自己掌握的产品。

     

    再排除 除了OpenID Connect之外的其他协议的平台,重点考虑对OpenID Connect支持较好的平台。

    另外,暂时只考虑Java语言实现的平台。

    那么就剩下,Apereo CAS、MITREid Connect、KeyCloak。

     

    首先说 Apereo CAS,号称支持各种协议,支持很多种语言的clients集成,而且它在业界也比较有名了,应该也比较成熟了。

    所以,我开始把它作为首选。然而,我下载它的Demo,调试了很多功能之后,几乎就要哭了。主要有以下问题:

    1)产品线铺得太宽,太冗余;

    2)项目太大(war包180多MB),源码和配置官方都不建议改,使用非常不灵活;

    3)配置项太多(估计有几千个配置项吧),文档写得太少,网上资料也很少(其实网上教程很多,但是99%都千篇一律的基础)。

    4)项目集成了太多东西,光是maven pom.xml文件都有7500行,而且是war包调试非常困难。

     

    弄了几天之后,终于决定放弃(并且想到以后要在上面做配置和二次开发,问题肯定不少,折磨人)

     

    再说 MITREid Connect,只支持OpenID Connect协议,但是算比较专业的,功能比较全,关键是开源的OpenID Connect Provider(OP)选择也不多,当然比商业的一些OP功能要弱。我试用了一下,比较顺利,源码也可以调试,但是基于Spring Security,还是比较复杂,而且从设计上讲,不算特别优雅。

     

    对CAS失望后,我就开始把 MITREid Connect当做主打,但明显感觉需要很多的二次开发工作(与CAS比,缺失了很多功能),而且代码还比较复杂。

     

    再说 KeyCloak,这也是一个集大成的平台,支持多种协议,服务器都支持 jetty、tomcat、WildFly、jboss等等,自带功能很强,和CAS有得一比:

    • CAS主打CAS,并支持其他协议,而KeyCloak主打OpenID Connect,并支持SAML2.0;

    • KeyCloak为后起之秀,为JBoss开源,背景够硬,而CAS也与时俱进,但相比而言,KeyCloak没有那么多历史包袱,从内到外都是全新,CAS只是看起来新,实则从设计到代码都是很旧的;

    • KeyCloak为JBoss团队设计和开发,设计优雅,文档比较清晰,这点比CAS要好得多;

    • 上手体验,KeyCloak上手非常容易,直接解压启动即可,CAS则较难,而且KeyCloak自带的Portal和相关功能很容易使用;

    • KeyCloak为JBoss核心项目,天然支持各种复杂的场景,当然CAS也比较成熟,但是CAS的成熟给人的感觉是后期一步一步加上去的,而非最初的设计就很成熟。

    另外注意,KeyCloak自带了权限控制模型,这个模型我感觉很好用,虽然没有Casbin、ladon等专业,但是应该能应对绝大多数的项目。再说了,很多项目都有自己的权限控制模型,要接管统一管理,难度不小,这方面后续还得进一步讨论。

    值得一提的是,Keycloak前端采用了AngularJS技术,这个技术在国外很流行,但是在国内还是Vue和React用得多。

     

    KeyCloak是无意间看到的,刚开始觉得可能非常复杂,没怎么想去碰他,直到后来看了几次它的文档之后,发现功能确实强大,而且文档写得还不错,就下载试了一下,发现设计优美,上手简单,功能强大,且完全满足甚至超越了我的期望,堪称完美。

     

    崩溃2:看这些平台的文档,看得我都精神崩溃了。

    崩溃3:试用这些平台,调试Demo程序,调得我精神崩溃。

     

    综上,结论如下:

        开发平台,最终决定用KeyCloak,功能强大,设计优美,文档清晰,要说缺点可能比较复杂,改代码比较难,但自带的功能基本足够了;

        备选 MITREid Connect,因为它功能简陋,设计普通,需要很多很多的二次开发才行,如果要做到KeyCloak那样的功能,没有个三、五个月怕是搞不定。

        放弃 Apereo CAS,虽说功能强大,但是功能杂乱,代码十分复杂,文档简陋,应对复杂的场景和特殊的需求,实在难以搞定。

     

    3、确定采用哪个开发框架(Shiro、Spring Security、Pac4j、MITreid、Nimbus等)

        先说 Java界两大开源安全框架:Shiro和 Spring Security

        我从 2013年接触 Spring Security时,就感觉不太好,一个集大成的框架,但是太复杂了。

        而Shiro则给人感觉简单得多,而且功能足够了,这么多年都很稳定,和Spring集成也很简单。

        如果要用到一些高级功能,推荐用Spring Security,如果是一般应用,建议用Shiro。

     

    Spring Security是主流,很多第三方工具、应用,都支持:

        Apereo CAS、 KeyCloak和MITREid Connect 都是官方支持Spring Security,只有CAS官方支持Shiro。

     

    再说 Pac4j,官方说明是:

    Security engine for Java (authentication, authorization, multi frameworks): OAuth, CAS, SAML, OpenID Connect, LDAP, JWT...

    它是CAS团队开源的一套组件,主要作者都是 Jérôme Leleu(leleuj)。

    个人感觉,Pac4j就是从CAS剥离出来的一套比较纯粹、干净的组件。

     

    由于比较简单、纯粹,而且又有CAS团队多年的经验沉淀,我还是比较推荐用这个组件。

    它和 Spring Security、Shiro都能很好的集成。而且它从设计上,就是和Spring无关的,它支持在非Spring环境下使用。

     

    再说 MITreid client,这个就是 MITREid Connect官方提供的client库,强依赖于 Spring Security,设计上也只 支持OpenID Connect,所以如果不是用 MITREid Connect + Spring Security,个人不是很建议用它。

     

    再说Nimbus,这是一个主流OpenID Connect商业产品(Connect2id Ltd.)随便开源的一个 支持OAuth和OIDC的库,只是开源只读代码而已,没有社区成员参与维护。一般不建议用,除非完全把它的代码私有化,自行维护。

     

    综上,结论如下:

    在选择 KeyCloak 平台的前提下,

    开发框架,首选 Spring Security,因为 KeyCloak官方提供了对 Spring Security很好的支持,直接用官方的spring-security-adapters就可以。

    次选 Shiro + Pac4j(buji-pac4j),因为它支持标准的OIDC,所以接入 KeyCloak 也没问题。

     

     

     

    展开全文
  • 对于Saas业内在用户统一身份认证及授权管理领域,主要关注 4 个方面(4A管理)): 集中账号管理(Account)、集中认证管理(Authentication)、集中授权管理(Authorization)和集中审计管理(Audit), 简称 4A ...

    对于 Saas业内在用户统一身份认证及授权管理领域,主要关注 4 个方面(4A管理)):
          集中账号管理(Account)、集中认证管理(Authentication)、集中授权管理(Authorization)和集中审计管理(Audit), 简称 4A 管理。
    后来发展了 IAM(Identity and Access Management,即身份识别与访问管理)的相关技术,在云计算等领域应用广泛。整体来说,不管是 4A 还是 IAM 还是未来可能的其他技术方案,都可以归纳为『统一身份治理』的范畴。本文基于『统一身份治理』的概念提出了统一身份管理系统(Unified Identity Management System)的设计思路。

    一、统一身份管理系统(Unified Identity Management System)

          统一身份管理系统(简称 UIMS)可以认是多租户软件架构的升级版,通常是整个平台帐号和权限管控的基础性系统,平台下所有系统的账户管理、身份认证、用户授权、权限控制等行为都必须经由该系统处理,提供帐号密码管理、基本资料管理、角色权限管理等功能。UIMS 基于『统一身份治理』的概念,可划分为两级账户体系、基础权限模块和基础信息模块三大模块。其中两级账户体系将账户分为组织实体帐号和个人实体账户两大类,个人实体从属于组织实体,也可以不从属任何组织实体,且个人实体可同时从属于多个组织实体;基础权限模块将各业务系统的资源权限进行统一管理和授权;基础信息模块用于描述组织实体和个人实体的基本信息,如组织实体名称、地址、法人,个人实体姓名、电话号码、性别等基础信息。UIMS 提供统一的 API 与各子系统连接。

    从整个平台的角度来看,UIMS 除了提供上述功能和服务,还应该满足以下需求:

    编号需求描述
    1软件授权云平台付费授权机制,可按时间、功能、数量等进行付费授权
    2组织入驻允许组织主动申请加入平台
    3实名认证个人实名认证、组织实名认证
    4资质审核个人和组织的资质审核,如对获得的证书或荣誉进行审核
    5组织绑定个人账户绑定组织,与组织建立关联关系
    6组织解绑个人账户与组织进行解绑
    7账户注销个人账户注销,并销毁所有个人资料和档案
    8统一登录即 SSO
    9统一注册提供统一的用户注册页面

    因此,从功能的角度可以将 UIMS 划分为以下模块:

    一)功能
    
        系统设置 System Configuration
          系统标识管理 System Identifiers Management
          服务账户管理 Service Accounts Management
        
        账户实体管理 Account Entities Management
          组织实体管理 Organization Entities Management
          组织架构管理 Organization Management
          个体账户管理 Individual Accounts Management
        
        账户权限管理 Account Permissions Management
          用户组管理 User Group Management
          角色管理 User Roles Management
          资源权限管理 Permission Resources Management
          权限策略组管理 Permission Group Management
        
        认证审核管理 Authentication Management
          个人认证管理 Individual Authentication Management
          组织认证管理 Organization Authentication Management
          资质审核管理 Qualification Management
        
        付费授权管理 Authorization Management
          组织授权管理 Organization Authorization Management
      
    二)页面
    
        统一注册页面 Unified Signup Page
        统一登录页面 Unified Signin Page
        组织入驻页面 Organization Signup Page
        个人实名认证页面 Individual Authentication Page
        组织实名认证页面 Organization Authentication Page
    
    三)API
    
        鉴权相关的APIs
        业务相关的APIs
    

    其中组织绑定和解绑的功能,可以放到『组织实体管理』 或『个体账户管理』的功能中。需要注意的是,组织绑定与解绑功能,是否与业务系统关联,下文将进行阐述。

    二、两级账户体系和基础权限模块

    基于『统一身份治理』的理念,采用两级账户体系(UIMS 提供接口)实现多系统融合的平台级 SAAS。两级账户体系将账户类别分为组织实体和个人实体两类(详见下文用户分类)。个人实体可以从属于组织实体(可以从属于多个组织实体),也可以不从属。个人账户体系和组织账户体系在云平台内享有的权限是不一样的,虽然大部分功能和服务两个体系的实体均可独立使用,互不干扰,但部分功能和服务有所不同。

    1. 基本原则

    平台级 SAAS 模式账户体系应遵循以下几个基本原则:

    • 个人账户统一原则:个人账户一次注册,全平台通用,类似于全网通行证和 SSO,注册和登录都在 UIMS 进行。
    • 业务权限独立原则:每个子系统的权限体系是独立管理的。『个人账户统一原则』明确了账户体系是统一的,但是对于每个子系统而言,每个账户所能使用的功能和服务,所能查看的数据权限是独立维护的,比如 XXX 公司(组织)-研发T3组(用户组)-张三(用户)-研发人员(角色),在 CRM 系统中,拥有的资源权限(详见下文),与其在 OA 系统中的所拥有的资源权限肯定是不一致的。
    • 组织实体隔离原则:不同的组织实体之间,是相互隔离,独立管理的。每个组织实体可以自行组织自己的组织体系、账户体系和权限体系。不同的组织实体资源权限也是隔离的。
    • 从属关系隔离原则:个体账户与组织实体的从属关系是基于单独的业务系统存在的,『个人账户统一原则』明确的仅是个人账户的全网统一,但组织实体、从属关系并没有统一,并且是隔离的。比如在 CRM 系统中,张三(用户)从属于 XXXX 公司(组织),但在 OA 系统中,张三(用户)默认是不从属于任何组织的,从属关系受到具体业务系统的影响。事实上,这个原则是非强制的,具体取决于各自的业务逻辑和业务场景。如果要简化从属关系的管理,那么可以不遵循此原则,即个体账户与组织实体的从属关系是全平台统一的,与业务系统无关,但这会为降低平台的灵活性和扩展性。灵活性和复杂度之间通常要做一个取舍。

    2. 权限原则

    类似于 RBAC 原则,平台的权限体系采用 OS-RBAC 的概念:

    • OS:O 代表 Organization 组织,S 代表 System 业务系统,即权限是受到组织实体和业务系统双重影响的。
    • RBAC:基于角色的访问控制。
    • OS-RBAC:组织实体-业务系统-用户-角色-权限标识。分为两种情况:一种是有从属组织的个人账户;另一种是无从属组织的个人账户,后者无组织,但同样遵守 RBAC 的权限限定,且其权限标识体系允许组织为空。
    • 资源标识:分为逻辑资源和实体资源。逻辑资源如菜单、页面、表单、按钮组、按钮、字段等功能型资源,或人员档案、考勤记录、任务记录、位置数据、积分、电子钱包等数据资源;实体资源如椅子、凳子、电脑、车辆等实物资产,另外有时候部分逻辑资源也可以归纳为实体资源,如电子照片、视频文件、音乐文件等。
    • 条件标识:权限的约束条件,主要有可见组织架构范围限定、时间限定、区域限定等。例如某权限仅财务部可见,有效期至11月2号,这里『财务部』属于可见组织架构范围限定,『至11月2号』则是时间限定。
    • 权限标识:用于标识账户实体在指定的条件下拥有访问某项功能、查看某些数据的权限。资源标识和条件标识与权限标识关联,权限标识与角色关联,角色与用户关联。例如张三(用户)-研发人员(角色)-拥有『研发部』所有人员档案的增上改查权限。
    • 业务系统标识符:受『业务权限独立原则』的约束,与传统的资源权限有所不同的是,所有权限标识都与具体的业务系统关联,例如企业CRM系统就是一个业务系统,具体的权限标识与业务系统有直接的关系,例如菜单、表单、页面、按钮、图片等资源。
    • 权限策略组:权限策略组是在 OS-RBAC 基础上设置的,为简化权限配置的一种辅助手段,在实际应用中可以不创建策略组。策略组分为平台级策略组和业务系统级别的策略组,两种策略组的作用域仅限于相同组织实体内部,但对于无从属组织的个人账户除外。策略组与角色类似,可以将资源权限绑定到策略组中,但不同之处是,平台级策略组可以横跨业务系统进行平台级的资源权限绑定。因为账户体系跨越多个子系统,在遵循『业务权限独立原则』的限定下,每个子系统都需要做一套权限配置,操作上较为繁琐,因此充分运用策略组可以大大简化权限配置工作。平台可以内置多套常用的策略组,终端用户可以直接选用策略组,也可以基于某个策略组为基础,进行修改。值得注意的是,策略组的作用域仅限于相同组织实体内部,即策略组可以横跨业务系统,但不能同时作用于多个组织实体。
    • 权限交集:与 RBAC2 的静态职责分离-角色互斥原则相反,平台采用多角色权限并集的设计。
    RBAC模型
    RBAC模型

    『权限标识』示例:在企业CRM系统[1]中,在2019年3月5号以前[2],对百度科技[3],研发中心[4],在广东区域[5]的所有人事档案[6]拥有只读权限[7]。

    1. [1]业务系统标识;
    2. [2]条件标识:时间限定;
    3. [3]组织实体标识;
    4. [4]条件标识:可见组织架构范围限定;
    5. [5]条件标识:区域范围限定;
    6. [6]资源标识;
    7. [7]权限类型。

    3. 从属关系梳理

    为简单起见,我们将不遵守『从属关系隔离原则』,即用户实体与组织实体的从属关系与业务系统无关。系统涉及的实体类型有:

    • 业务系统(系统标识)
    • 服务账户(客户端)
    • 个人账户实体
    • 组织账户实体
    • 组织架构
    • 用户组(非必选项)
    • 角色实体
    • 权限实体
    • 资源实体
    • 限定条件实体
    • 权限策略组(非必选项)

    3.1 与组织实体强关联的实体

    基于『组织实体隔离原则』,这类实体类型不能脱离组织实体独立存在。

    • 组织架构
    • 角色实体
    • 权限实体
    • 资源实体
    • 限定条件实体

    由于组织架构不能脱离组织实体单独存在,因此当用户实体绑定组织架构时,该用户实体必须隶属于该组织架构所从属的组织实体。同理可知以下从属关系遵从同样的约束——即每对关系的两个实体对象必须属于相同的组织实体:

    • 用户与角色
    • 角色与权限
    • 资源与权限
    • 限定条件与权限

    3.2 与业务系统强关联的实体

    基于『业务系统隔离原则』,这类实体类型不能脱离业务系统独立存在。

    • 权限实体
    • 资源实体
    • 限定条件实体

    4. 实体类型

    基于以上各项原则,实体类型又分为以下几种情况:

    • 组织实体(未认证):在组织实体的模式下,可以按照组织的管理要求,独立设置一套组织架构、账户和数据权限体系,比如设置下属企业、分公司、部门、岗位职务、角色权限,组织实体缺省分配一个管理员帐户,拥有全部权限,由管理员初始化配置信息。
    • 组织实体(已认证):拥有未认证组织实体的所有权利,但已认证的实体通常拥有更多的配额更少的功能限制,此外有些特定的业务功能和业务流程,必须是实名认证的实体才能使用,比如支付和交易。
    • 个人实体(未认证):在个人实体的模式下,享受的权利由具体的业务系统决定,原则上个人实体作为独立的账户类型,应该享有基本的功能权限和数据权限,如个人中心的各项功能等。
    • 个人实体(已认证):与组织实体(已认证)类似。
    • 个人实体(未从属于组织):未从属组织的个人实体账户,与上述个人实体类型一致。
    • 个人实体(从属单个组织):从属单个组织的个人实体账户,除了具备个人实体账户的原本权利外,还受到组织权限的约束,原本个人实体不享受的权利,可能现在可以享受,原本享受的权利,可能现在不可以享受了。
    • 个人实体(从属多个组织):当个人实体账户从属于多个组织时,除了个人账户原本拥有的权利外,所从属的组织所带来的权利须遵循『组织实体隔离原则』,且受到『从属关系隔离原则』的约束,具体的权利配置由各个业务系统独立管理。这里有两种情况:一是在用户登录时,必须选择所属的组织机构,类似于 LOL 游戏,在登录时须选择所属的区域和服务器;二是在用户登录后,可以自由选择组织实体,类似于阿里云或华为云的区域选择,在用户未选择所属组织时,应当按照未从属于组织的个人实体账户对待。
    • 组织管理员:组织管理员拥有该组织内部的全部资源权限,例如可以创建个人账户,在个人未完成首次登录前,可以删除(解雇),修改,在个人完成登录后,则权限移交给了个人;删除(解雇)时,只是个人脱离组织,个人不再拥有组织员工的权限,在组织内的个人工作经历仍然保留,组织清除离职员工,则这些在职经历将不为企业可管理,但个人自己可见,不可变更。

    5. 用户分类
     

    用户分类
    用户分类

     

    6. 组织分类

    组织分类
    组织分类

    三、基础信息模块

    基础信息,主要针对个人实体和组织实体,如企业工商信息、通用信息等要满足灵活扩展的需求,实体的类型种类繁多,随着业务场景的变化,信息结构的变化也可能比较频繁。在技术上建议采用以下两种方式应对:

    1. EAV 数据模型

    EAV 即 Entity(实体)-Attribute(属性)-Value(值)数据模型,将传统的 ORM 映射模型——即实体属性与数据库表字段一一对应的模型,变换为实体属性与数据表的行记录一一对应的模型。EAV 模型大大增加了数据映射和相关业务逻辑的复杂程度,但是具备高度的灵活性,能够满足随时变化的信息结构,满足动态变更的实体结构、满足字段级权限控制、满足字段级数据版本历史等功能。

    2. 采用松散型数据结构的数据库方案

    其中的代表便是 MongoDB:一个介于关系数据库和非关系数据库之间的分布式文件存储数据库产品,在 CAP 理论中属于 CP 范畴,支持松散数据结构,支持复杂的混合数据类型,支持 JSON 和文档存储。采用此方案的优势比较明显,除了能够满足 EAV 模型所具备的大部分功能外,还大大简化了技术复杂度,支持分布式部署,推荐采用此方案。

    3. 信息分类

    平台的信息主要分为基础信息和业务信息两大类。基础信息分为个人实体信息和组织实体信息,主要描述实体的基本信息、通用信息,与业务相关性不大,例如姓名、性别、身份证号码、手机号码、企业通用信息、企业工商信息等。业务信息由各业务系统自行管理和维护,UIMS 不涉及。

    实体类别信息类别信息范围备注
    个人信息基础信息昵称、性别默认公开
    个人信息基础信息身份证信息、籍贯、性别、出生日期、学历、工作履历、电话号码、通信地址、照片、银行卡号须用户授权收集和公开
    个人信息业务信息LBS数据须用户授权收集和公开
    个人信息业务信息用户移动终端的设备信息,包括IP地址、Mac地址、操作系统信息、设备型号、识别码等须用户授权收集和公开
    个人信息业务信息用户的行为信息,包括操作记录,cookies,通过平台编辑或传送的文字、图片、语音或视频信息等须用户授权收集和公开
    个人信息业务信息用户喜好、特长、手工标签、自动标签、社交互动信息等须用户授权收集和公开
    组织信息基础信息组织工商信息:名称、法人、营业范围、注册日期、注册资本、通信地址、工商注册号、公司类型、纳税人识别号默认公开,自动审核
    组织信息基础信息组织介绍、品牌介绍、微信公众号、企业官网、对外联络电话、客服电话默认公开,须人工审核
    组织信息基础信息企业资质、股权结构、对外投资、工商登记变更记录、企业年报、公司发展历程、行政许可须组织授权收集和公开
    组织信息基础信息核心团队和成员、融资历程、核心产品、公司规模、知识产权须组织授权收集和公开
    组织信息基础信息组织架构、组织成员档案、司法风险、法律诉讼须组织授权收集和公开

    所有与信息收集、储存、处理及数据安全有关的书面政策,应当出具《隐私政策》并进行声明。部分组织信息由于可在网上公开查到,且是法定必须公布的信息,因此可以默认公开。

    四、其他功能

    一)软件授权

    基于两级账户体系,建立云平台付费授权机制,针对用户账户和组织账户进行独立授权。根据产品的商业策略,可执行灵活的付费模式:

    • 时效限制:年付、季付、月付,不同时效费用不同。
    • 功能限制:授权不同的功能,费用不同。
    • 数量限制:最大组织数量限制、最大用户数量限制,不同的数量费用不同。

    二)组织入驻

    UIMS 应提供一个组织实体注册登记的流程,允许组织主动提交基本信息,开户入驻平台。此外,应提供在管理后台手工录入组织开户的功能。

    三)实名认证

    分为个人账户实名认证和组织账户实名认证,尽量通过技术手段自动执行实名认证的审核过程,减少甚至取消人工干预。UIMS 应提供实名认证的功能和流程。

    四)资质审核

    资质审核分为两部分:一是部分实体实名认证过程中的人工核查;二是对实体提交的额外资质进行技术或人工审核。

    五)组织绑定

    基于『从属关系隔离原则』,个人账户应在具体的业务系统中绑定组织账户,绑定过程分为两种类型:一是由组织管理员手工创建的从属个人账户,另一个是个人账户申请加入某个组织。业务系统应该提供此功能和流程。例如,个人注册帐号后,可主动登记绑定组织,对已注册登记的组织则要该组织管理员审核,未在系统中注册登记的组织,则始终处于待审核状态。

    六)组织解绑

    允许个人账户解除与组织之间的从属关系。解绑分为两种情况:一是个人账户主动解除关系,二是组织管理员解绑、解雇或清除雇员(个人账户)。其中第一种个人解绑的,应当由组织进行审核批准,个人申请解除绑定关系,组织进行审核,但是是否需要审核,应交由具体的业务系统自行决定。

    七)间接雇佣(从属)关系

    雇佣(从属)关系分为直接雇佣与间接雇佣关系。例如保安员在某保安公司入职(直接雇佣),在某物业作保安(间接雇佣)。考虑两种办法标识间接雇佣关系:

    • 增加服务单位(项目点、物业社区)的实体概念
    • 利用组织内部的组织机构体系,将间接雇佣单位作为当前组织的分支机构进行处理。

    八)账户注销

    分为个人账户的注销和组织账户的注销。UIMS 应提供相应的页面完成账户注销的操作。

    九)私有化部署

    原则上拒绝私有化部署,但对于特定的客户,考虑私有化部署。私有化部署须考虑版本升级问题,在软件架构设计时,尽量遵循业务系统和技术系统分离的原则,并抽离公共模块,最大限度为私有部署的版本提供升级服务。

    五、总结

    总体来说,统一身份管理系统要做的事情有这么几件:

    • 定义实体
    1. 业务系统实体
    2. 服务账户实体(客户端)
    3. 组织实体
    4. 组织架构
    5. 个人实体
    6. 角色实体
    7. 权限标识
    8. 资源标识
    9. 条件标识
    • 处理上述各实体之间的关系,并提供数据结构
    • 提供鉴权 APIs 和业务 APIs
    • 提供其他功能:统一注册功能(页面和流程)、统一登录功能、软件授权
      、组织入驻、组织绑定/解绑、资质审查。

    转自:https://www.jianshu.com/p/990d8acfdb69

    参考:http://www.ruanaaly.com

    展开全文
  • AD域实现统一用户管理

    万次阅读 2019-02-25 13:12:46
    AD域服务  什么是目录(directory)呢? 日常生活中使用的电话薄内记录着亲朋好友的姓名、电话与地址等数据,它就是 telephone ...如果这些目录内的数据能够由系统加以整理,用户就能够容易且迅速地查找到所...
      1. AD域服务

        什么是目录(directory)呢?

    日常生活中使用的电话薄内记录着亲朋好友的姓名、电话与地址等数据,它就是 telephone directory(电话目录);计算机中的文件系统(file system)内记录着文件的文件名、大小与日期等数据,它就是 file directory(文件目录)。

    如果这些目录内的数据能够由系统加以整理,用户就能够容易且迅速地查找到所需的数据,而 directory service(目录服务)提供的服务,就是要达到此目的。在现实生活中,查号台也是一种目录;在 Internet 上,百度和谷歌提供的搜索功能也是一种目录服务。

    Active Directory 域内的 directory database(目录数据库)被用来存储用户账户、计算机账户、打印机和共享文件夹等对象,而提供目录服务的组件就是 Active Directory (活动目录)域服务(Active Directory Domain Service,AD DS),它负责目录数据库的存储、添加、删除、修改与查询等操作。一般适用于一个局域网内。

    在 AD 域服务(AD DS)内,AD 就是一个命名空间(Namespace)。利用 AD,我们可以通过对象名称来找到与这个对象有关的所有信息。

    在 TCP/IP 网络环境内利用 Domain Name System(DNS)来解析主机名与 IP 地址的对应关系,也就是利用 DNS 来解析来得到主机的 IP 地址。除此之外,AD 域服务也与 DNS 紧密结合在一起,它的域命名空间也是采用 DNS 架构,因此域名采用 DNS 格式来命名,例如可以将 AD 域的域名命名为 moonxy.com。

     

      1. LDAP简介

    LDAP(Lightweight Directory Access Protocol),轻量目录访问协议,是一种用来查询与更新 Active Directory 的目录服务通信协议。AD 域服务利用 LDAP 命名路径(LDAP naming path)来表示对象在 AD 内的位置,以便用它来访问 AD 内的对象。

             LDAP数据的组织方式(如下图所示), 在树根一般定义国家(c=CN)或域名(dc=com),在其下则往往定义一个或多个组织 (Organization)(o=Acme)或组织单元(Organizational units) (ou=People)。一个组织单元可能包含诸如所有雇员、大楼内的所有设备等信息。此外,LDAP支持对条目能够和必须支持哪些属性进行控制,这是有一个特殊的称为对象类别(objectClass)的属性来实现的。该属性的值决定了该条目必须遵循的一些规则,其规定了该条目能够及至少应该包含哪些属性。例如:inetOrgPerson对象类需要支持sn(surname)和cn(common name)属性,但也可以包含可选的如邮件,电话号码等属性。

     

    1.2 LDAP常见简称

    简介

    全称

    用途

    o

    Organization

    组织/公司

    ou

    Organization Unit

    组织单元

    c

    Country

    国家

    dc

    Domain Component

    域名

    sn

    Suer Name

    真实名称

    cn

    Common Name

    常用名称

    dn

    Distiguished Name

    唯一标识名

    uid

    User ID

    用户标识

     

    1.3 AD域与LDAP的区别

    Windows AD(Active Directory)域应该是LDAP的一个应用实例,而不应该是LDAP本身。Windows AD域的用户、权限管理应该是微软公司使用LDAP存储了一些数据来解决域控这个具体问题,AD域提供了相关的用户接口,我们可以把AD域当做微软定制的LDAP服务器。Active Directory先实现一个LDAP服务器,然后自己先用这个LDAP服务器实现了自己的一个具体应用。

    2创建AD域服务,导入证书

    创建AD域服务这里不在多说,网上有很多详细教程。详细介绍一下AD域服务证书问题。

    情况1:不涉及密码,状态操作。不需要证书

    可以使用默认389端口 使用springboot 集成LDAP配置 就可以完成基本操作

    情况 2:功能要求密码,状态操作

       这种情况下需要使用AD域的636端口,SSL协议访问,并导入服务器的AD域服务证书  。 网上有很多教程说本地使用ie浏览器访问服务器IP,下载证书,亲测没什么用还增加难度。可以使用最简单的方式 服务器导出证书后直接复制到本地。

    证书导入: 默认密码 changeit

    开始 >> 运行 >> 输入cmd 进入dos命令行 >>cd 到jdk1.5\jre\lib\security这个目录下,敲以下命令(使用此命令可以省略指定路径):

    keytool -import -alias cacerts -keystore cacerts -file d:\software\AKAZAM-Mail.cer

    红底 : 为证书导入起的别名,可以随便起

    绿底 : 为从服务器导出的证书路径(命令错误就给路径加上双引号 “”)

           如果在连接的代码中报错误

           javax.naming.CommunicationException: 192.168.0.10:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 192.168.0.10 found]

           换JDK 1.8-161 或 尝试属于下列导入证书方式(该步骤需写路径):

    1. 然后“开始-运行->cmd”进入控制台,

    2. 用CD命令切换到jdk的bin目录下,

    3. 输入命令:“keytool -import -keystore 证书名.keystore  -file cer文件的路径”,

    4. 从而导入一个新的证书,进入jdk的bin目录能够看到你新命名的那个扩展名为keystore的文件,

    5. 然后将更改密码的时候设置的证书路径更改为刚刚生成的这个证书的文件路径。(代码中体现)

    3连接AD域服务

    使用Softera LDAP Browser连接服务 方便查看AD域用户信息

    1. 创建连接

     

     

    1. 输入连接名(随便输入)

     

    1. 输入IP地址 点击FetchBaseDNs选择域名(默认389端口)

     

    1. 输入用户名+@域名

    这里Principal 一定记得输入 用户名+@完整域名

     

    1. 连接完成

           从图一中可以查看AD域的组织和用户数据,图一红框中就是组织单元。但是AD域中也有组的概念,切记第一点,用户需要创建到组织单元中,然后可以根据用户角色分配到组里。

           第二点,图二是用户nie 的ObjectClass属性值。图三是组织单元的ObjectClass属性值

    包括其他的 组,联系人,计算机。。。都有对应的ObjectClass值。在创建,查找,删除,修改用户,组织单元等 都需要指定objectClass(在下面代码中详细介绍)

     

    4. 集成LDAP配置

         在pom.xml中添加Maven依赖

    <!-- LDAP Module -->

    <dependency>

      <groupId>org.springframework.boot</groupId>

      <artifactId>spring-boot-starter-data-ldap</artifactId>

    </dependency>

    <!-- JPA Module -->

    <dependency>

      <groupId>org.springframework.boot</groupId>

      <artifactId>spring-boot-starter-data-jpa</artifactId>

    </dependency>

    项目依赖包spring-boot-starter-data-ldap是Spring Boot封装的对LDAP自动化配置的实现,它是基于spring-data-ldap来对LDAP服务端进行具体操作的

    5 编写代码

    先贴一下基本属性 第30行 使用636端口

    5.1 打开链接

    (197)该ip需 636端口

    (198)在上述导入证书步骤中,如使用第一种可省略此步代码,使用第二种方式必须指定 .keystore文件的路径,

    (200)在创建用户时需要设置密码和用户状态,所以需要指定SSL协议

    此步骤如果用户验证失败,直接抛出异常 err code 49 可以先尝试把用户名加 @域名,如果还是err code 49 那就是你账号密码有问题

     

              5.2关闭连接

    直接调用dc.close()方法即可

     

    5.3添加账户

    这里创建账户调用使用

    public DirContext createSubcontext(String name, Attributes attrs)

           参数name 为创建用户的完整distinguishedName  CN= , OU= ,DC= ,DC= 形式

           Attrs 则为用户属性(见下图)

     

    这里有个异常

    Remain name 。。。的错,此错误为 distinguishedName  属性值错误

    方法通过及添加完成

    5.4设置添加属性

    上图红框 :设置添加的属性。 此处4个属性值 对应用户。 也可更改为组,计算机等 可以在步骤三 最后图二中查看属性值。

     

    上图绿框 :(170)设置用户常用名CN 基本属性之一

                    (171)用户状态:66048[普通帐户,无密码到期]

                                                 546 用户禁用    (还有很多其他状态自行百度)

                    (174)编码格式不可改其他的,“\” 密码 “\”  \不可省略

                     (170 - 175) 这里的attrs 可以添加更多的数据,例如姓,电话,公司,职位等等,只需要put方法第一个参数设置成对应的属性,可在3连接AD域服务 软件上查看

    这里有一点 cn 要和 distinguishedName 中的CN= 一致

                                                                                

     

     

     

     

     

     

     

     

     

     

     

     

     

    在学习操作AD域中 , 难点就在于导入服务器证书,以ssl协议连接,并创建用户设置密码,设置状态。至于其他的操作,直接调用 LdapContext 的方法及可实现难度不大。

    6 参考文章

    Windows Server 2008 R2 活动目录服务安装  链接

    安装AD域服务证书 win server 2008  链接   证书导入参考 本文档步骤2

    安装AD域服务证书 win server 2012  链接   证书导入参考 本文档步骤2

    Spring LDAP Reference  官方文档    链接 

    博客  链接

    操作AD域  err code 总计

     

     

    展开全文
  • 一步步使用SpringBoot结合Vue实现登录用户管理功能

    千次阅读 多人点赞 2021-01-26 20:25:08
    前后端分离开发是当今开发的主流。本篇文章从零开始,一步步使用SpringBoot结合Vue来实现日常开发中最常见的登录功能,以及登录之后对用户管理功能。通过这个例子,可以快速入门SpringBoot+Vue前后端分离的开发。
  • 统一登录门户系统

    千次阅读 2020-04-04 21:02:19
    常见的统一登录要求,还是基于一个统一的入口,由统一登录入口完成登录后,可以自由访问其他系统,而其他系统的用户登录应跳转到统一登录入口。 可能存在的问题: 1.用户系统如何建立,如何解决存量用户。 2.应...
  • 每天都有分享,完全是免费订阅,...智学网查分_智学网官网登录_智学网查分登录方法温馨提示:学生用户,用户名和初始密码均为准考证号家长用户,请使用注册时的手机号登录。1、打开网页,在地址栏里输入www.zhixue.c...
  • 统一用户认证和单点登录解决方案

    万次阅读 2018-08-22 09:13:36
    本文以某新闻单位多媒体数据库系统为例,提出建立企业用户认证中心,实现基于安全策略的统一用户管理、认证和单点登录,解决用户在同时使用多个应用系统时所遇到的重复登录问题。 随着信息技术和网络技术的迅猛发展...
  • 统一用户权限管理系统(正式版)

    千次阅读 2015-01-08 21:11:56
    系统名称:统一用户权限管理系统  演示地址:http://tdog7.oschina.mopaas.com/    简介:本系统为统一的细粒度授权管理和用户统一身份管理及单点认证支撑平台。每个接入的系统都支持自定义权限、配置细粒度...
  • 统一用户认证和单点登录和授权的原理与流程

    万次阅读 多人点赞 2019-02-02 13:58:09
    彻底搞懂统一用户认证和用户单点登录1. 前言2. 原理1. 统一用户认证介绍2. 单点登录原理介绍3. OAuth 2.0的统一用户认证1. OAuth 2.0协议和流程简介2. 授权码模式3. 简化模式4. 密码模式5. 客户端模式6. 授权码模式...
  • 统一认证:移动互联网时代的用户账号一站式管理平台 随着智能手机已经完全普及化,移动互联网时代开始真正的到来,随之而来的也是庞大的应用开发市场。1. 应用(APP)登录移动互联网时代,用户获取app的途径更加...
  • 普通用户登录管理登录区分

    万次阅读 2017-03-24 11:43:37
    查阅的资料,先缝合成自己的,写登录注册页面是要注意的细节。 http://bbs.csdn.net/topics/390888578<?php error_reporting(0); @session_start(); require_once 'conn/conn.php'; $user_name=$_POST['name'];...
  • 我所在的公司比较大,内部的各种管理系统和业务系统比较多,然而所有的系统都可以用公司的OA的员工工号和密码直接进行登录 (当然登录界面都是一个就是内部OA门户)。从进入公司以来我就一直有个问题,这是怎么做到...
  • 客户在曹工的成本系统登录后,想要应用我们的企业定额系统还需在使用相同或者不同的用户名重新登录一次,才能使用企业定额,这样给客户带来极为不佳的使用体验。 在年初做系统规划时,我们组已经认识到现有系统的...
  • 统一用户管理数据库UML

    千次阅读 2018-10-03 15:57:45
  • 统一用户权限管理系统

    千次阅读 2015-01-30 14:53:27
    本系统为统一的细粒度授权管理用户统一身份管理及单点认证支撑平台。每个接入的系统都支持自定义权限、配置细粒度用户权限和资源灵活配置。
  • 分布式系统统一登录的实现

    千次阅读 2019-11-25 15:02:49
    一、 运用Redis缓存将Token存入缓存; 将 session 全部存放到 ...用户登录的时候如果通过鉴权体系的鉴定,可以生成 Token 数据,以 Token 作为键名,用户登录信息作为值,写入到 Redis 中,设置过期时间,并将 ...
  • 关于各系统(统一登录) 前端(vue)

    千次阅读 2020-02-26 15:00:41
    类似于登录淘宝或者天猫跳转到统一登录页面,登录成功携带参数跳转页面 需求:多个后台管理系统 => 未登录 => 跳转到统一登录界面 => 登录成功携带token => 需要登录系统截取token添加到请求头 => ...
  • Linux用户管理

    千次阅读 2018-09-05 10:52:30
    一、用户管理的配置文件 1、配置文件 (1)、/etc/passwd的文件格式 (2)、用户类型 (3)、伪用户 一、与系统相关:比如有些伪用户是与系统的某些操作相关(比如关机,重启等等,会调用伪用户的身份)。...
  • Springboot + Spring Security 实现前后端分离登录认证及权限控制前言本文主要的功能文章目录一、数据库表设计建表语句初始化表数据语句二、Spring Security核心配置:WebSecurityConfig三、用户登录认证逻辑:...
  • 统一权限管理系统 -- UPMS(1)

    千次阅读 2019-10-01 03:53:48
    如果一家公司存在多套系统,那么有一个统一的权限管理系统是尤为重要的。如果没有一个统一的全信管控,那么意味着每个系统都要有自己的权限管控。这对于程序开发来讲是极其浪费成本的,也是灾难性的。 在项目周期...
  • 业内在用户统一身份认证及授权管理领域,主要关注 4 个方面:集中账号管理(Account)、集中认证管理(Authentication)、集中授权管理(Authorization)和集中审计管理(Audit), 简称 4A 管理。后来发展了 IAM...
  • 很多时候,我们在构建系统的时候都会自己创建用户管理体系,这对于开发人员来说并不是什么难事,但是当我们需要维护多个不同系统并且相同用户跨系统使用的情况下,如果每个系统维护自己的用户信息,那么此时用户信息...
  • zutuanxue用户管理

    千次阅读 2020-06-17 15:32:27
    一、用户和组的相关概念 账号的概念和分类 账号:是一种用来记录单个用户或是多个用户的数据。Linux中每一个合法的用户都必须要拥有账号,才能使用 。它不仅可以用来验证用户身份,还决定了一个用户在系统中可以从事...
  • 绝对完全跨域统一单点登录登出

    万次阅读 热门讨论 2018-05-06 16:38:17
    如:淘宝与天猫,登出也如此,一个系统登出,其他系统的登录也随之失效,这就是统一单点登录登出。 这里配置三个web系统,一个用户中心系统为栗子 配置hosts实现跨域: 127.0.0.1 ssofront.ljtest.xxxx.com #...
  • 浅谈统一权限管理平台

    万次阅读 2018-06-20 19:16:19
    本文通过建设的统一权限管理平台,从而能够更加灵活、迅速的实现身份权限管理需求,提升公司身份权限管控水平,降低身份安全控制风险。 中国论文网 /1/view-7200261.htm  关键词:系统架构;统一权限;管理平台 ...
  • 公司子系统整合统一登录的架构

    千次阅读 2018-12-27 11:49:13
    众多子系统的登录页面不再使用,所有登录统一登录页面,登录时选择你要登录的系统,这里以我改造的安全管理系统为例。 在安全管理系统项目中加入一个整合的jar包,其实就是一个拦截器,拦截所有请求,看请求中...
  • 统一用户认证中心

    万次阅读 2018-06-22 15:24:04
    解决思路:提出一个统一认证中心,对所有的登陆逻辑做统一处理,此服务可调用 不同的管理系统,如:操作员系统、终端用户系统、QQ开放平台竺,可复合调用组装,再将结果返回;实现架构图:说明:1. API Gateway(ora....

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 591,556
精华内容 236,622
关键字:

统一登录后用户怎么管理