共通のアーキテクチャを実現するシングルポイントのログ
ディレクトリ
- 1.シングルサインオンとは何ですか
- 2.ユーザーログイン
- 2.1認証
- 2.2ライセンス
- ファーストパーティのログインを達成するために2.3アーキテクチャ
- 2.4アーキテクチャは、サードパーティのログインを可能にします
- ファーストパーティとサードパーティのログインログインの間に2.5認可の差
- 概要2.6ログインアーキテクチャ
- 3.アクセス制御
- 3.1分散型認証アーキテクチャ
- 3.2集中型の認証アーキテクチャ
- 分散型と集中認証3.3長所と短所
- 3.4アクセス制御の粒度
- 3.4.1 HTTPメソッドレベル
- 3.4.2 APIインタフェースレベル
- 3.4.3 APIの実装レベル
- 4.まとめ
- 5.参考文献
インターネットアプリケーションの開発、ユーザーのログインやアプリケーションのアクセス制御サービスは、ユーザーがログオンし、アクセス制御が必要なインターネットアプリケーション開発されているので、直接、アプリケーションの安全な動作に影響を与えるだけでなく、ユーザーのプライバシーに影響を与える、重要な部分であります機能性成分は、認証、認可、認証およびアクセス制御機能の4つのリンクに関するものです。この紙櫛シングルサインオン（シングル・サインオン）インターネットアプリケーション開発技術のアーキテクチャの実装は、ユーザのログインの単一点も統一されたユーザーのログインとしても知られています。
- 注1：この記事では、インターネットアプリケーションの開発について説明し、主に二つの技術のウェブおよびモバイルアプリケーション開発を指します。
- 注2：本論文の認証、認可、認証およびアクセス制御からで議論概念の定義この記事。あなたがこの記事を読む前にそのため、前の記事を読むことをお勧めします。
1.シングルサインオンとは何ですか
SSOシングルサインオン、ユーザーのログインだけで、この単一の機能を実現する、ユーザーフレンドリーな使用、対応するコンポーネントを提供するために、より多くの技術アーキテクチャ、統一された認証、認可、認証およびアクセス制御を提供するソリューションであり、かつ高速アクセスの開発と応用。そのため、シングルサインオンは、シンプルなログインモジュールではありません。
シングルサインオンは、文字通り、それはユーザーが同じアカウントが異なるアプリケーション・サービスにアクセスすることができ、かつ複数の認証を達成することができます（入力したユーザ名とパスワードを1回）後にユーザーがログオンすることができます使用させることです。シングルサインオンは大幅にユーザーのログイン操作を容易にすることができます。これは、ビューシングルサインオンのユーザの視点からです。
シングルサインオンのためのもう一つの重要な需要も、アプリケーションがドッキングを使用することは簡単です、検討する必要があるアプリケーションは、単純に、簡単かつ迅速にシングルサインオン機能にアクセスできるように、シングルサインオンアーキテクチャは、適切なクライアントコンポーネントと構成を提供する必要があり、しばらくセキュリティ制御を実現するための権限。
そのため、ユーザーのログインおよびアクセス制御を含んセキュリティアーキテクチャとして、シングルサインオン技術は2つの機能、後者関わる認証とアクセス制御部門、元を含む認証と認可の側面を必要とします。
2.ユーザーログイン
ユーザーログインプロセスは、一般的に、これらの2つのセグメントが、多くの場合、ユーザーを識別つまり、一緒に発生するだけでなく、許可されたユーザを完了するために、ユーザーの認証と認可の二つの側面を伴います。
、プロバイダ・ログイン機能モジュールは、ログに分割することができ、第三者への最初のログは、2つのタイプを登録します
- ファーストパーティのログイン：アプリケーション自体が提供するログインサービス。それは自分自身と自分のログインアプリケーションであるため、大幅に承認プロセスを促進するサービスやアプリケーションサービス間の相互信頼性、にログオンので。
- そのようなマイクロ文字を介するなど第三者が提供するアプリケーションログインサービス、サードパーティのユーザーアカウントのログインを使用し、QQ、Alipayのアカウントでログオンなどする：ログイン。現在では、業界標準の使用主要なインターネットのオープンプラットフォームのほとんどのOAuth 2.0認証コードモードをサードパーティのログインを達成するために。
ファーストパーティとサードパーティのログインログインには、ユーザ認証技術の大きな違いはありませんが、違いの承認プロセスがあります。具体的な承認プロセスは、以下を達成するためにアーキテクチャの違いを議論し。
2.1認証
インターネットの発展には、一般的な認証モード、
- ユーザー名とパスワード
- SMS確認コード
- 二次元コードスキャンモバイルアプリケーション
- ユーザージェスチャー
- ユーザーに関連付けられたワンタイムパスワードに基づいて、時系列
ディスカッション・ペーパーを容易にするために、ユーザーがログオンする単純なHTTP基本認証（HTTPベーシック認証）方法を使用しますが、それは、ユーザー名とパスワードの方法です。複数の認証方法は、一般的に拡張インタフェースアイデンティティ・プロバイダを介して達成することができます。
2.2ライセンス
ユーザーが正常にログインすると、あなたは適切な認証情報を取得することができます。
インターネットアプリケーション開発の分野では、実装技術は、主に以下のものを含む認可します
- Webサーバーを使用してセッションメカニズム、ユーザーの認証情報を維持するために、アクセスセッション
- Webブラウザからクッキーメカニズムは、クッキーは、ウェブサイトのユーザー認証情報を保持します
- 許可トークン（トークン）を発行し、法的に有効なトークンは、ユーザーの認証情報を保持します
どちらのフロントには、Web開発において一般的であるブラウザのサポートを必要とします。モバイルや他のアプリケーションがクッキーシーンを使用することはできませんのために、しばしば達成し、リクエストヘッダ方式で認証トークン情報を運ぶために使用すること。
注文承認物品支持ウェブ・アプリケーション及びモバイルアプリケーションにおいて、権限情報認証トークン（トークン）の形態で提供されますモバイルアプリケーションのための方法によってヘッダを運び、一方、Webアプリケーションのために、認証トークンは、クッキーによって要求内で運ば、リクエストインチ
ファーストパーティのログインを達成するために2.3アーキテクチャ
それは自分自身のサインオンを実装したものですので、サービスやアプリケーションサービスの間でログオンするので大幅に承認プロセスを促進することになる、お互いを信頼し。
最初のパーティーシーンのログでは、それは一般的に二つの方法で許可することができ、
- アプリケーションがブラウザを介してアクセスする場合は、クッキードメインによって許可と共有することができます
- アプリケーションはブラウザアクセス、またはできないではない場合、あなたは直接クッキーの技術を介してユーザ名とパスワードによって許可交換することができます。アプリケーションサービスが信頼されたアプリケーションに基づいて、前提条件であるユーザー名やパスワードなどの機密情報を、得ることができることに留意すべきです。
（開発する）コードの実装
シンプルなフレームワークは、以下のことを達成するために、
含む単一サイン・アーキテクチャで実装必要なコンポーネントおよび機能の図明るい赤線と正方形、
- シングルサインオンモジュール：ユーザのログイン・インターフェースを提供する、ジャンプすることが可能に返し、発行した認証トークン（トークン）、チェックサムキャンセル
- Webフィルタ：それ以外の場合はエラーメッセージを返し、認証トークンのリクエストを取得し、要求が通過正当であるかどうか確認してください。
次のようにWebアプリケーションの場合は、クッキーを共有することにより、道の承認、全体のプロセスの相互作用を得るため、
- ユーザーがブラウザを介してWebサービスにアクセス
- 一般的なWebフィルタチェック要求でバックエンドサービス要求が許可トークンが見つかったされていない場合、は、ユーザーがログオンできるように、ユーザーのログインモジュールにジャンプ
- ログインに成功すると、ユーザー名とパスワードを入力するユーザー、クッキーの許可トークンは、お使いのブラウザに保存されます
- 背面のユーザーアクセスのページにジャンプするユーザーは、その要求は自動的に承認トークンクッキーをもたらします
- 合法的かつ有効な、バックエンドサービスにアクセスできるユーザーは、それ以外の場合はエラーメッセージを返す場合はクッキーでWebフィルタのバックエンドサービス検証要求の許可トークンは、ユーザーが再度ログインするように要求されます。
- ユーザーがログオフすると、Webアプリケーションサービスの認証トークンはクッキーをクリアするブラウザに保存され、Redisのトークンをログオフしています。
次のようにモバイルアプリケーションでは、ユーザー名とパスワードを経由して、全体のプロセスの相互作用を許可を取得、
- ユーザーがモバイルアプリケーションを開き、アプリケーションがログオンするようにユーザーに要求します
- ログインに成功すると、ユーザー名とパスワードを入力するユーザーは、トークンは、モバイルアプリケーション、ストレージに戻され、携帯電話上のアプリケーションストレージスペースが許可されます。
- アプリケーションを入力した後、モバイルアプリケーションアクセスバックエンドサービスは、認証トークンはリクエストヘッダで運ば
- 合法的かつ有効な場合は許可トークンを検証するための要求での一般的なWebフィルタヘッダー内のバックエンドサービスは、ユーザーがバックエンドサービスにアクセスする、またはログオンするようにユーザーに促すことができます。
- ユーザーがログオフすると、モバイルアプリケーションは、認証トークン、およびトークンのRedisのキャンセルを削除します。
モバイルアプリケーションは、Webアプリケーションを好きではないので、ブラウザのスルーモードクッキーは自動的に承認情報を運ぶ、モバイルアプリケーションは、自身の記憶処理と承認情報要求を必要とします。
2.4アーキテクチャは、サードパーティのログインを可能にします
こうしたマイクロ手紙、QQ、淘宝網のアカウントなど、ユーザーアカウントを登録するステップを排除するだけでなく、スペアとして最初のパーティ、ユーザーが直接に人気のあるサードパーティのアカウントログを使用することができ、サードパーティのログイン最大の利点と比較するとログインユーザメモリのアプリケーションは、それによってユーザアクセスのコストを削減、ユーザーの急速な利用を促進するために、パスワードのトラブルを占めています。
サードパーティのログインのために、現在、主要なインターネットのオープンプラットフォームで、彼らは、業界標準のOAuth 2.0認証コードモードを使用します。OAuth 2.0の認証コードモードと詳細は別の記事で説明されるために、ここでは拡張されていません。
（開発する）コードの実装
シンプルなフレームワークは、以下のことを達成するために、
含むシングルサインアーキテクチャで実装必要なコンポーネントおよび機能の図明るい赤線と正方形、
- OAuth 2.0の認証サーバ：、ユーザーのログイン認証を提供して返します認証トークン（トークン）の発行、検証やキャンセルを達成ジャンプ
- トークンインターフェース：クライアントは認証コードを介した認証トークンと引き換えに、呼び出し、
- Webフィルタ：それ以外の場合はエラーメッセージを返し、認証トークンのリクエストを取得し、要求が通過正当であるかどうか確認してください。
図の認可を取得するためのアプリケーション、Webおよびモバイルアプリケーションの2種類、実質的に同一の方法の2種類があります。
Webアプリケーションの場合は、対話型のプロセス全体を次の、
- 用户通过浏览器访问Web服务
- 后端服务中一个通用的web filter校验请求，若发现请求中没有授权令牌，则跳转至第三方用户登录服务
- 在第三方登录服务中，用户输入用户名和密码，若登录成功，则跳转回web应用，并返回授权码
- Web应用将获取到的授权码，调用后端Token接口，该接口将根据授权码+应用ID+应用Secret，向第三方申请授权令牌，若一切正常，第三方颁发授权令牌给Web应用，Web应用将获取到的授权令牌存储在浏览器的cookie中。
- 将用户跳转回用户的初始访问页面，此时请求中cookie将自动带上授权令牌
- 后端服务的web filter校验请求cookie中的授权令牌，若合法且有效，则用户可以正常访问后端服务，否则返回错误消息，提示用户再次登录。
- 用户注销登录时，web应用服务将存储在浏览器cookie中的授权令牌清除，并注销redis中的令牌。
移动应用和web应用的流程类似，整个流程交互如下，
- 用户打开移动应用，应用提示用户登录，并将用户导向第三方登录服务
- 在第三方登录服务中，用户输入用户名和密码，若登录成功，则跳转回移动应用，并返回授权码给移动应用。
- 移动应用将获取到的授权码，调用后端Token接口，该接口将根据授权码+应用ID+应用Secret，向第三方申请授权令牌，若一切正常，第三方颁发授权令牌给移动应用，移动应用将获取到的授权令牌存储在手机上的应用存储空间。
- 进入应用后，移动应用访问后端服务，授权令牌携带在请求header中
- 后端服务中一个通用的web filter对请求header中的授权令牌进行校验，若合法且有效，则用户可以正常访问后端服务，否则提示用户登录。
- 用户注销登录时，移动应用将授权令牌清除，并注销redis中的令牌。
2.5 第一方登录和第三方登录的授权区别
第一方登录和第三方登录之间最大的区别在于授权流程。
第一方登录在用户被认证之后，即刻颁发授权令牌，应用服务一般无需介入授权流程。而第三方登录在用户认证之后，先颁发给授权码给应用服务，应用服务还需根据这个授权码去换取授权令牌，换句话说，应用服务需介入授权流程。
这里有个问题是，为什么在第三方登录中，应用服务会被介入授权流程？主要原因是在第三方登录场景中，除了用户需要被认证，应用服务本身也需要被认证。而在第一方登录场景，只需用户认证，应用服务本身是可信的，其无需被认证。
2.6 登录架构实现小结
为了对比上述两个登录架构实现的不同之处，下面将各自的特点小结为下表，
| 第一方登录架构 | 第三方登录架构 | |
|---|---|---|
| 登录功能 | 由己方提供 | 由第三方提供 使用第三方的用户账户 |
| 登录实现 | 通过http basic auth | OAuth 2.0授权码模式 |
| 应用是否可信 | 可信，应用可以接触用户密码等敏感信息，应用本身无需认证 | 不可信 |
| 应用是否需要认证 | 否 | 是 |
| 应用是否可以接触用户密码等敏感信息 | 是 | 否 |
| 授权过程 | 登录成功后颁发token | 1. 登录成功后返回授权码给应用 2. 应用根据授权码和应用ID换取token |
| Web页面的服务请求 | 通过cookie带上token | 通过cookie带上token |
| 移动应用的服务请求 | 通过header带上token | 通过header带上token |
3. 权限控制
在互联网应用开发中，安全控制在后端服务中实现。整个权限控制的过程一般会涉及到鉴权和权限控制两个环节。
鉴权的实现方式一般有两种，
- 通过授权服务器：由于授权令牌是由授权服务器颁发的，所以由授权服务器校验也是自然而然的事情。这种方式会导致授权服务器的访问热点问题，为了缓解热点，缓存是必要配置。
- 通过加解密：通过授权令牌的加解密方式，确认令牌的合法性。即，授权服务器颁发一个通过公钥加密的授权令牌，在校验的时候若能够通过私钥解密，则该令牌为合法令牌。这种方式有一个缺点是，一旦令牌注销失效后，信息无法及时通知到解密方。对令牌的注销时效性要求不高的场景下，可以使用这种方式，其大大缓解了授权服务器的访问热点问题。
若根据鉴权的架构方式，则可分为分布式和集中式两大类，
- 分布式：通过后端web服务的filter实现分布式控制，在各个服务应用的运行实例中进行鉴权
- 集中式：通过网关实现集中式控制，在访问流量的入口进行鉴权
鉴权后访问控制粒度从大到小有如下三种分类，
- Http方法级别
- API接口级别
- API实现级别
下面将对鉴权的架构实现和控制粒度进行详细讨论。
3.1 分布式鉴权架构
分布式鉴权的架构如下图，
在web应用开发中，可以通过web应用服务的filter功能，对所有请求中的授权令牌进行校验，实现分布式鉴权。分布式鉴权实现简单，可以快速实现并使用，但随着应用服务架构的水平和垂直扩展，filter的升级将会成为头痛的问题。
3.2 集中式鉴权架构
集中式鉴权的架构如下图，
通过网关，在访问流量的入口，对所有请求中的授权令牌进行校验，实现集中式鉴权。集中式鉴权减轻了应用服务的接入成本，但会增加了网关的性能负荷。
3.3 分布式和集中式鉴权的优缺点
分布式鉴权和集中式鉴权有各自的优缺点小结为下表，
| 分布式鉴权 | 集中式鉴权 | |
|---|---|---|
| 优点 | 简单，可以分散校验热点 | 应用服务接入成本低，方便鉴权管理 |
| 缺点 | filter版本升级困难，需要对所有应用服务进行依赖更新 | 需要网关的支持，并且鉴权操作将增加网关的性能负荷 |
| 应用场景 | 简单的互联网web应用开发 | 大型互联网web应用开发 |
3.4 访问控制的粒度
鉴权后就会得到请求访问的权限，接下来则是根据权限来控制请求访问的允许或禁止。
根据访问控制粒度从大到小，可划分出如下几个控制级别，
- Http方法级别
- API接口级别
- API实现级别
3.4.1 HTTP方法级别
若web应用服务是按照Restful的规范来开发接口服务，则可以根据Restful的定义对Http的不同方法实现不同的访问控制。
根据Restful的规范定义，Http方法具有如下安全性和幂等性的特点，
| HTTP方法 | Restful定义 | 安全性 | 幂等性 |
|---|---|---|---|
| GET | 获取资源 | 是 | 是 |
| POST | 创建资源 | 否 | 否 |
| PUT | 更新资源 | 否 | 是 |
| DELETE | 删除资源 | 否 | 是 |
| HEADER | 资源元信息 | 是 | 是 |
| OPTIONS | 是 | 是 |
表中，安全性和幂等性的概念如下,
- 安全性是指该方法不改变资源的状态，即不改变后台数据
- 幂等性是指该方法执行的同一操作多次，其结果保持一致
可以看到，对于安全的HTTP方法，比如GET操作，其访问控制可以宽松。而对于一些非安全操作，则需要根据不同权限来控制访问请求。在实际应用过程中，可以执行如下的权限控制规则，
- 匿名用户：可以执行GET请求
- 普通登录用户：可以执行GET、POST、PUT请求
- 管理员：可以执行所有类别请求
总的来说，根据Http请求的方法和URI进行访问控制。
3.4.2 API接口级别
这个权限控制的粒度深入到代码控制层（Controller），不同的权限，可以访问不同的API接口。
一个spring mvc的代码样例如下，
@Controller
public class TokenApp { @PreAuthorize("hasAuthority('ROLE_ADMIN')") public Principal getUserInfo(Principal me){ return me; } } 上面的代码表示，具有管理员角色的权限才能获取当前用户信息。
这个粒度的权限访问控制基本可以满足大多数应用场景需求。
3.4.3 API实现级别
在应用的实现级别进行控制，这个控制粒度非常细，其根据不同权限返回不一样的调用结果，例如，同样是查看学生列表，若是班主任，则返回一个班的学生列表，若是校长，则返回一个学校的学生列表。
4. 小结
本文主要从用户登录和权限控制两大功能方面梳理其架构实现，这些实现可以结合实际的应用场景，进行相应的匹配。
| 第一方登录 | 第三方登录 | |
|---|---|---|
| 分布式权限控制 | 1. 简单web应用场景 2. 登录服务和应用服务相互可信 3. 登录服务和应用服务同域，可以授权共享 |
1. 简单web应用场景 2. 登录服务和应用服务相互不可信 3. 登录服务和应用服务不同域，各自独立开发部署，无法授权共享 4. 应用和登录服务模块彻底解耦，通过跨域跳转实现用户登录。 |
| 集中式权限控制 | 1. 大型web应用场景，有网关组件部署 | 1. 大型web应用场景，有网关组件部署 2. 快速接入第三方用户 |