Mobile BI 移动商务智能的身份认证

这篇文章介绍了Mobile BI(移动商务智能)使用过程中涉及的各种身份认证的方式，主要目的是对这些方式的原理进行理解，略少涉及这些原理在Mobile BI中的具体实现。

文章的具体内容包括：序言, IServer Authentication, Mobile Server Authentication, SSO, Windows, Kerberos, Usher, SAML, OAuth, Authentication Filter, 引用。

序言

身份认证，也就是Authentication，经常与Authorization一起出现：

Authentication 认证：用户是谁
Authorization 授权：用户能做什么

但是通常而言，用户会与一定的权限绑定，这也就意味着一旦确认用户的身份，自然就获取了相应的权限。

先列一下传统Mobile BI现在支持的认证模式：

Mobile Server Authentication
  - Anonymous
  - Basic
  - NT Credentials/Windows
  - Trusted: HTML Form
  - Integrated Authentication: Kerberos

Intelligence Server Authentication
  - Standard
  - NT Credentials/Windows
  - LDAP
  - Warehouse Pass Through/Database
  - Simple Security Plugin/Trusted
  - Integrated Authentication: Kerberos
  - Usher Integration

至于新的Mobile BI，已经模糊了Mobile Server与IServer认证的界限，对于Client来说，只有一个Server，所以他现在支持的认证模式：

Authentication
- Standard/LDAP/Databse
- Usher
- Authentication Filter
  - Standard
  - SAML Form
  - SAML Usher
  - Kerberos
  - Anonymous
  - HTML Form Trusted
  - Basic Trusted

IServer Authentication

BI服务器端认证，是指移动用户对应在IServer上的用户，这些都是通用的服务器端的用户认证模式，对于移动端来说，只需要知道移动端的用户是如何对应到服务器端账户，相应的在移动端如何处理就可以了。

"Standard", "LDAP", "Database": 这三者在移动端可以视为同一种，因为只需要提供用户名和密码即可，而不需要额外处理

"Windows", "Trusted", "Kerberos": 依赖于Mobile Server的认证，映射到IServer的用户，不需要给IServer再次提供认证信息

"Usher": 依赖于Usher的认证，跟Tusted类似，不同点在于Usher不用在Mobile Server的认证上

Mobile Server Authentication

因为与Web Server同源，事实上这里的认证和普通网页服务器认证方式是一致的：

"Anonymous", "Basic", "Windows": Web Server基础的三种授权认证方式

"Trusted": 特指SSO认证方式，其实不能算是Mobile Server本身的，而是SSO Provider监控服务器端口，在Mobile Server层前面又加了一层，事实上在这种模式下，Mobile Server可以继续使用以上三种基础授权认证方式

"Kerberos": 一种票据分发的认证方式

SSO

SSO 概念

Wikipedia 对SSO的定义：

Single sign-on is a property of access control of multiple related, yet independent, software systems.

With this property, a user logs in with a single ID and password to gain access to a connected system or systems without using different usernames or passwords, or in some configurations seamlessly sign on at each system.

This is typically accomplished using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on (directory) servers. A simple version of single sign-on can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain.

简单的说使用SSO实现单点登录，避免对每个单一系统逐个登录。

SSO的优点显而易见：减少不必要的认证，加快验证速度，避免暴露用户密码，降低IT成本等。

因为不同的单一系统的认证机制存在不同，SSO需要保存初始认证的信息以供转换成不同认证机制的授权信息。与SSO共享认证模式类似的授权认证方式还存在很多：

Other shared authentication schemes include OAuth, OpenID, OpenID Connect and Facebook Connect.

这里与SSO不同点在于：这些方式需要在每次访问不同应用时输入登录验证信息。

SSO的通用配置可以通过以下几个方式实现：

• Kerberos Based：TGT票据分发
• Smart Card Based：智能卡、IC卡，带芯片的
• Integrated Windows Authentication：Microsoft产品，指代SPNEGO, Kerberos, NTLMSSP等认证协议
• SAML：基于XML的安全信息交换解决方案

SSO for Mobile BI

对于移动端来说，不需要知道SSO到底是如何实现的，只需要知道在移动端需要处理什么样的验证：

• Basic Authentication：使用了这种方式的SSO，在移动端的表现跟Mobile Server的Basic Authentication一致，具体表现为收到NSURLAuthenticationMethodHTTPBasic/NSURLAuthenticationMethodDefault类型的验证请求。
• Form Authentication： 使用这种方式的SSO，在移动端表现为，当一个网络请求发出去后，会被SSO重定向为一个HTML Form的登录页面。

针对"SSO Form Authentication"这种情况，我们的Mobile BI采取了一种很简洁的解决方案：

当检测到来自非Mobile BI服务器的回复，并且回复内容包含"Form"时，就认定这是一个"SSO Form Authentication"

使用WebView来加载具体的登录页面，移动端不处理具体的登录内容，只待登录完成，页面被重新定向为初始的网络请求时，认定SSO的认证已经完成，便继续之前的工作。

为实现这个解决方案，我们要求SSO Provider必须满足两条基本要求：

SSO 认证完成后必须重定向为初始的URL，这样我们才能通过比对，在不监测具体SSO登录页面内容的情况下确认SSO认证完成

SSO在认证成功后需要自动将"token"设置在"cookie"中，这样，对于后续的网络请求，SSO自动检测这个"token"而确定认证信息

目前比较广泛使用的SSO Provider包括 "Siteminder", "Tivoli" 以及 "Ping Federate"，他们都可以按照上面的要求进行配置。

Issue Open Window

UIWebView不支持弹出小窗口，有一些Form页面可能包含此类代码，这样导致在移动端会报错NSURLErrorDomain error -999，解决方法是直接在移动端禁止掉窗口弹出的逻辑：
[_webView stringByEvaluatingJavaScriptFromString:@"window.open = function(url, name, features){ /* ignore */ };"];

Issue Blank Screen

"Ping Federate"的一个例子，在登录后页面变为空白，登录失败，调试后发现"Frame load interrupted"的错误日志。

对于这种空白页面的问题，大多数是因为SSO的配置没有满足前面的两个基本要求，对于这个例子，我们发现：

• 登录完成后没有重定向为初始URL，以致页面空白
• "token"被直接附在了回复的URL上，而不是设置在"Cookie"中，导致后继请求失败。

"Ping Federate"对于"opentoken"的"response"有如下三种方式：

Query: returns a 302 response, but posts the opentoken in the URL

Form post: Doesn’t put the opentoken in the URL, but sends back a 303 status code.

Cookie: stores the opentoken in a cookie, leaves the URL intacts and sends back a 302 response

我们期待的是第三种"Cookie"的方式

Windows

也可称为"集成windows"身份验证，可分为"NTLM"和"Negotiate"两种，这里的"Negotiate"是指根据实际情况选择使用"Kerberos"/"NTLM"(Kerberos拥有较高的安全性，为首选项)。需要分清的是，"windows"这里只负责身份的认证，而后继的数据传输如何保护，就不在此范围内了(这是SSL的事了)。

参见Windows Authentication Overview的定义：

NTLM is a challenge-response style authentication protocol.In addition to authentication, the NTLM protocol optionally provides for session security—specifically message integrity and confidentiality through signing and sealing functions in NTLM.

"NTLM"验证时需要向服务器传递用户的用户名和密码，并在服务器端进行验证，在这里用户名是明码传送，密码是使用密码哈希值加密(DES)服务器返回的咨询码再传送。

与此对应，"Kerberos"验证时只需向服务器传递客户端访问IIS的验证票，服务器通过这个票据来确认客户端身份，而不需要传送用户的密码。

打开Windows的IIS，我们可以看到有多种认证模式，其中的"Windows Authentication"就是我们常说的Windows认证模式，可以看到它可以具体选择采用"Negotiate"/"NTLM"其一的方式：

"Forms"认证方式与一个登陆页面相关联：

"ASP.NET Impersonation"身份模拟，使用特定的用户执行特定的程序：

Windows Authentication in Server
在开发中我们发现在使用Mobile BI的Server的时候，"Anonymous"/"Windows"在IIS上配置的时候都需要打开"ASP.NET Impersonation"，否则无法有效。

Kerberos

概念

来自Wikipedia Kerberos的定义：

Kerberos is a computer network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.

Kerberos这个名字来自希腊神话，是一只守护着冥界的长着三个头颅的神犬，而在"Kerberos Authentication"中，也有着关于认证的三方：Client, Server, KDC。

需要记住的一些概念：

• KDC /Key Distribution Center 密钥分发中心
  • AS /Authentication Server 认证服务器
  • TGS /Ticket Granting Server 票据授权服务器
  • Account Database：保存账号信息，知道Master Key
• TGT /Ticket Granting Ticket 票据授权票据，票据的票据
• KServer-Client：Client和Server之间的对称密钥，为Session Key
  • Long-term Key/Master Key: 长期不变的Key，比如密码，用此加密的数据不应该在网络上传输；将密码Hash后的Hash Code，叫做Master Key，以便在不知道密码的情况下验证密码
  • Short-term Key/Session Key: 只在一段时间内有效，用于网络数据的传输
• Authenticator：证明信息，在Kerberos是关于Client的一些信息和当前时间的一个Timestamp
• Time Synchronization: 通过一个Time Service以便Client和Server端的时间同步
• 双向认证Mutual Authentication

下面我们通过三个子协议来了解Kerberos的认证过程：

Authentication Service Exchange
Client向KDC申请TGT：KDC的Authentication Service实现对Client身份的确认，并颁发给Client一个TGT。

"KRB_AS_REQ"即"Authentication Service Request"，这个由Client向KDC发送，Client使用"Master Key"对"KRB_AS_REQ"的主体部分进行加密，KDC通过Domain的Account Database获得该Client的Master Key。

"KRB_AS_REQ"包含内容

• Pre-Authentication Data: 包含用以证明自己身份的信息
  • 证明自己知道自己声称的那个account的password
  • 一般内容是一个被Client的Master Key加密过的Timestamp
• Client Name, Realm: 就是Domain name\Client
• Server Name: 非需要访问的那个Server，而是KDC的TGS的Server Name

AS验证发送方是否知道Client的Password来确认发送方的身份：从Account Database中拿到对应的Master Key对"Pre-Authentication Data"进行解密，验证为合法的Timestamp，即认证发送方提供的是正确的密码。

KRB_AS_REP 即 Authentication Service Response，这个是待验证通过后，AS发送给Client。

"KRB_AS_REP"包含内容：

• 被Client的Master Key加密过的Session Key
• 被KDC加密的TGT

TGT包含内容：

• Session Key: SKDC-Client, Logon Session Key
• Client Name + Realm: 就是Domain name\Client
• End Time: TGT到期时间

Client通过自己的Master Key对第一部分解密就可以获得Session Key，之后带着TGT就可以进行下一步：

Ticket Granting Service Exchange
Client通过获得TGT向KDC申请用于访问Server的Ticket：

"KRB_TGS_REQ"即"Ticket Granting Service Request"是由Client 向KDC中的TGS发送的，包含内容：

• TGT：被KDC的Master Key加密过
• Authenticator：用来证明TGT的拥有者就是自己，用TGT的方法和自己的Session Key加密
• Client Name + Realm: 就是Domain name\Client
• Server Name + Realm: 就是Domain name\Server

验证TGT是否属于这个Client的：

• 需要通过Client提供的Authenticator来证明
• 通过Master Key解密TGT，获得Logon Session Key
• 通过Logon Session Key解密Authenticator进行验证

"KRB_TGS_REP"即"Ticket Granting Service Response"，包含内容：

• 使用Logon Session Key(SKDC-Client)加密过的用于Client和Server的Session Key(SServer-Client)
• 使用Server的Master Key进行加密的Ticket

Ticket包含内容：

• Session Key：SServer-Client
• Client Name, Realm: 就是Domain name\Client
• End Time: Ticket的到期时间

Client使用Logon Session Key(SKDC-Client)解密第一部分获得Session Key(SServer-Client)，之后，就可以使用Session Key和Ticket与Server进行交互。

Kerberos之所以比NTLM高效，就在于认证可以直接通过Client和Server双方完成，而NTLM的每次认证都要通过一个双方信任的第三方来完成。

Client/Server Exchange
Client最终为了Server对自己的认证向其提交Ticket：Client通过TGS获得Session Key(SServer-Client)，随后创建用于证明自己就是Ticket的真正所有者的Authenticator，并使用Session Key(SServer-Client)进行加密。

"KRB_AP_REQ"即"Application Service Request"，包含内容：

• 加密过的Authenticator
• Ticket
• Flag：Client是否需要进行双向认证"Mutual Authentication"

Server通过自己的Master Key解密Ticket，从而获得Session Key(SServer-Client)，并以此来解密Authenticator，用于验证对方的身份。

如果需要双向验证，Server从Authenticator提取Timestamp，使用Session Key(SServer-Client)进行加密，发送给Client用于验证Server的身份。

更进一步：上面的协议有一个弱点，就是使用了Server Master Key来加密Ticket，而这个被加密的Ticket会在网络上传输，对于任何可能暴露Long Term Key的方法，都会存在安全隐患。

User2User Protocol

原来的Ticket是通过Server的Master Key进行加密的，而这个Master Key可以通过Account Database获得，替换为Server和KDC之间的SKDC-Server进行加密，而KDC是不知道这个key的。

Client对Server进行请求而获得Server和KDC之间的SKDC-Server，而Server跟Client类似，可以通过AS Exchange获得Server与KDC之间的SKDC-Server和一个封装了这个Key并被KDC的Master Key加密的TGT，Server缓存这个TGT

总体过程：

• AS Exchange: Client在此获得属于自己的TGT，凭此向KDC申请用于访问某个Server的Ticket
• 获得封装了Server和KDC的Session Key(SKDC-Server)的属于Server的TGT
  • 如果该TGT存在于Server的缓存中，则Server会直接将其返回给Client，否则通过AS Exchange从KDC获取
• TGS Exchange：Client通过向KDC提供自己的TGT，Server的TGT以及Authenticator向KDC申请用于访问Server的Ticket
  • KDC使用自己的Master Key解密Client的TGT获得SKDC-Client
  • 通过SKDC-Client 解密Authenticator验证发送者是否是TGT的真正拥有者
  • 验证通过再用自己的Master Key解密Server的TGT获得KDC和Server的SKDC-Server
  • 并用该Session Key加密Ticket返回给Client
• C/S Exchange: Client携带通过“KDC和Server的SKDC-Server”进行加密的Ticket和通过“Client和Server的SServer-Client”的Authenticator访问Server
  • Server通过SKDC-Server解密Ticket获得SServer-Client
  • 通过SServer-Client解密Authenticator实现对Client的验证

优点

较高的Performance：一旦Client获得Ticket，Server就能根据这个Ticket实现对Client的验证，而无需KDC的再次参与。

实现了双向认证Mutual Authentication：NTLM为单向

对Delegation的支持：作为在分布式环境中的重要功能，Impersonation允许Server在本地使用Logon的Account执行某些操作，Delegation需用Server将Logon的Account代入带另外一个Context执行相应的操作。NTLM仅支持Impersonation，Kerberos同时支持。

互操作性Interoperability：不同的平台进行广泛的互操作。

缺点

Single Point of Failure:

• 需要中央服务器持续工作，否则，如果Kerberos Server不工作的话，新的用户将不能够登录
• 解决：使用多台Kerberos服务器和缺陷认证机制弥补

Time Synchronization

• 票据具有一定有效期，需要保证主机与Kerberos的时钟同步
• 解决：网络时间协议

No Standardized Administration Protocol

• 管理协议没有标准化，在服务器实现工具中有一些差别

Centralized KDC

• 所有用户使用的密钥都在KDC服务器中，使用同步密码的时候，一旦KDC有安全威胁，将对所有用户产生安全威胁

Kerberos要求用户账号、客户端、服务都拥有与KDC之间的安全连接(相同的Domain，或者拥有可信任关系的Domain)，所以Kerberos不能够使用在类似于开放性的网络或者云环境里面，对于未知、不可信的客户端。

使用不安全的DES，自2014年，Microsoft发现漏洞，现在推荐使用AES

后记
Kerberos的认证过程概念颇多，非常复杂，这篇文章 kerberos认证原理---讲的非常细致，易懂值得好好读上几遍。

Kerberos for Mobile BI

SPNEGO Kerberos Authentication
MicroSoft在Kerberos上的应用，也是Windows Authentication的默认选项。Windows在每一个“域控制器”应用KDC认证服务，其域同Kerberos中的realm功能类似：

Kerberos客户端使用基于SSPI的Windows安全提供者，初始Kerberos认证同WinLogon的单次登录进行了集成，而Kerberos KDC也同运行在域控制器中的安全服务进行了集成，并使用活动目录作为用户和组的账号数据库

Windows中应用了Kerberos协议的扩展，除共享密钥外，还支持基于公/私钥对的身份认证机制。Kerberos公钥认证的扩展允许客户端在请求一个初始TGT时使用私钥，而KDC则使用公钥来验证请求，该公钥是从存储在活动目录中用户对象的X.509证书中获取的

• SPN: Service Principal Name
  • 用于关联KDC的Account
• GSS-API: Generic Security Service Application Program Interface
  • 一个API，用于Authentication，一般用在Kerberos上
• SPNEGO: Simple and Protected GSSAPI Negotiation Mechanism
  • 一种机制，协调Client和Server之间的Authentication
  • 常用在"Microsoft's HTTP Negotiate authentication extension"
• SSPI: Security Support Provider Interface
  • Windows使用，类似于GSS-API

在Mobile BI中主要考虑移动产品下实现Kerberos，而我们的实现遵循标准的OS支持流程。

iOS
从iOS7.0开始支持Enterprise SSO，内置Kerberos 5客户端，可以实现从KDC获取TGT。

安装配置描述文件Profile(后缀mobileconfig)，"PayloadType"类别设为"com.apple.sso"，安装时需要输入用户名(realm)，然后通过Safari或者App访问指定网站时，系统会弹出要求Password的窗口来验证这个User，以便从KDC获取TGT票据。然后在Ticket有效期内，用户不需要再次登录。

    PayloadContent
    
        
            PayloadType
            com.apple.sso
...
            Kerberos
            
                Realm
                AD-DOMAIN.MYCOMPANY.COM
                URLPrefixMatches
                
                    https://kerbenabledapp.mycompany.com
                
                AppIdentifierMatches
                
                    com.apple.mobilesafari
...

Android

Android OS暂时不支持Kerberos

Usher

Usher是Mobile BI的的企业级安全解决方案，在我们这个上下文场景里，就是一个身份认证的提供商，它有自己的服务器以及客户端。具体的细节在此不多说，只记录一个重要的处理Token的改动：

初始版本是Mobile BI App通过安装在同一机器上的Usher App进行授权并取得token，然后使用这个token与Mobile Server进行通信，而Mobile Server会与Usher Server验证token的有效性。

更新版本是Mobile BI App会首先访问Usher Server取到一个没有激活的token以及QR Code，Mobile BI App会使用这个QR Code请求Usher App授权并激活这个token，接下来，就会使用这个token与Mobile Server进行通信。

应用在另一个App中的方式有点类似于Kerberos的票据分发，Mobile BI App会首先访问Usher Server取到一个session和QR code，接着Mobile BI App会使用这个QR Code请求Usher App授权，接着Mobile BI App会使用这个session请求Usher Server获得一个token，接着使用这个token与Mobile Server进行通信。

SAML

概念

SAML Security Assertion Markup Language 安全声明(断言)标记语言：一个基于XML的标准，用于在不同的安全域(Security Domain)之间交换认证和授权数据。多使用于SSO场合中，作用类似于OpenID、OAuth等。

关键点：
断言 做出判断的语言
安全 公钥、私钥、签名、加密，保证断言的安全，防止被假冒篡改等

相关三方：
IDP Identity Provider 身份提供者
SP Service Provider 服务提供者
Client 用户

这张图比较清晰的表示出SAML的使用场景：

首先SP和IDP需要互相信任，并且拥有对方的公钥以便验证和通信。

用户访问SP，会获得一个SAML的认证请求数据包：

    https://sp.example.com/SAML2
    

这个包会放在HTML FORM的一个隐藏的域中，这个Form自带一段JS代码出发自动提交，而指向的地址就是IDP：

    
    ... other input parameter....
    



document.form[0].submit();

下面就是IDP的认证，可以是一个Form的认证页面，也可能是Windows等方式，一旦IDP确认你的身份，会生成“断言”，证明你的身份以及权限，这个会通过私钥签名（只有SP可以解析）：

...
    
     ...
     
     
     ...
     

这个断言包含在“response”中返回给客户端：

      https://idp.example.org/SAML2
      
     ....................
    
  

类似的，这个会放在一个Form里返回，自动提交指向的地址是SP：

 

    
    
    ...
    
  

document.form[0].submit();

这样SP通过已有的公钥验证断言签名，以此来验证Client端的请求身份。

对SAML的标准有兴趣的话可以继续读一下SAML 2.0，SAML 2.0 Technical Overview，简单的来说就是：

• Assertion：断言的XML结构，节点的schema
• Protocols：协议，如何请求和回复消息
• Binding：绑定，用什么协议来承载这些消息，http，soap
• Profile：一整套认证的细节和步骤

SAML for Mobile BI

首先，前面提到的SSO的支持，包括SiteMinder、Tivoli、Oblix等是实现了SAML。而在Mobile BI中支持SAML，其实就是支持这些实现了SAML的Provider。

在现实的应用中，因为我们有两个版本的Mobile BI，对于传统版本的Mobile BI，在Client端的处理与对SSO的处理一致，都是通过自动识别Form后使用Web View加载登录页面。而对于新版本Mobile BI，处理的方式就有些不同了。

可以先看一下这个流程图，理解Web Server支持SAML的认证步骤：

1. Browser makes a request to web application secured by SAML Servlet Filter.
2. Request is intercepted by security filter. The security filter detects that request is not authenticated and redirects browser to Authentication Service (SSO).
3. Authentication Service engages into authentication conversation with end user or uses some other means to authenticate user.
4. After user is authenticated Authentication Service redirects browser back to service provider providing authentication information in form of SAML Assertion.
5. Security Filter verifies the Assertion, extracts from it user information necessary to login to IServer and stores it in HTTP Session. After this original request is resubmitted to web application
6. Web application uses user information from HTTP Session to login to IServer. Notice that web application and IServer interact in trusted mode. That means that web server doesn't need to pass user passwords in order to login to IServer.

简要提一下Web Server(Mobile Server)支持SAML的一些配置要求：

• 建立Web Server和IServer之间的信任连接，这样Web Server就不需要使用密码等登录IServer
• 支持SSL/TLS，即必须使用HTTPS
• 使Web Server支持SAML的JAR文件，相应的web.xml文件修改等
• 在SSO 环境中注册应用

对于Mobile Client端，因为是通过Mobile Server与IServer交流，所以事实上和Web Server类似，也需要通过SAML Servlet Filter的验证：

• 因为Client端支持不同的认证方式，所以需要先请求Mobile Server得到当前Client端可以支持的认证方式
• 用户选择SAML方式后，会转到Web View加载对应的获取Session的URL
• 这个URL会获得一个当前登录的Form页面，这里可以是一个显示用户名和密码输入框的页面，或者是一个要求Usher授权的页面
• Client端逻辑会检查当前Cookie里是否有SAML的login session存在(名为iSession)，来判断验证是否结束。
• 这个取出的session会被存储起来作为后续的request的参数使用

可以看到，不同于SSO的流程，SAML这里的流程是需要加载特定的URL获取登录页面，而SSO是被重定向为登录页面：

其实页面的具体内容可能一致，但是SSO的一般做法是监听Proxy并拦截所有的访问请求，而这里SAML的做法是在Web Server前加了一层Filter，而需要通过这个Filter，你需要访问特定的URL来登录；而这里对待Session也不同，SSO是自动在Cookie里识别，而SAML的处理是作为参数（只是这里实现的的特定方式，不具有普遍意义）

目前已验证的SSO Provider包括 Usher, ADFS等

ADFS Active Directory Federation Services 活动目录联合服务: ADFS 使用基于Claims的访问控制验证模型来实现联合认证。它提供 Web 单一登录技术，这样只要在会话的有效期内，就可对一次性的对用户所访问的多个Web应用程序进行验证。

OAuth

OAuth is not strictly an authentication scheme but an authorization protocol:

It provides a way for the users to grant access on their own behalf to other websites or applications using some access keys. The main purpose of the protocol is to exchange the access credentials required for the authentication and not the authentication itself.

简单来说OAuth是一种开放标准：在不让第三方触及到用户的账号信息的情况下，为用户资源的授权提供了一个安全而又开放的资源授权标准。

VS. OpenID

OAuth: authorization授权，用户能做什么
OpenID: authentication认证，用户是谁

OpenID也多用于Mobile，提供身份认证，比如使用微信的OpenID登录其他的应用，OpenID只是告诉对方“你是你”，而OAuth是告诉对方“可以使用我的东西”，更多的比较信息可以参见OAuth vs. SAML vs. OpenID Connect

现实情况是：很多授权网站其实只需要使用OpenID，但是却使用了OAuth，变相获得了用户相关的资源访问权限。

VS. SAML

SAML是一种标记语言，应用于：SSO, Identity Management, Federation。这里面与OAuth最相关的就是SSO：

OAuth is an authorization protocol for authorization of resource
SSO is a high-level term used to describe a scenario in which a user uses the same credentials to access multiple domains

简单的说就是：OAuth是一种关于资源授权的授权协议，而SSO描述的是一种用户单点登录的使用场景。而更细节的SAML与OAuth的比较包括：SAML限定使用XML，而OAuth可以是Binary/JSON/SAML；SAML多用于企业级SSO的场景，而OAuth多用于网络资源的授权等等。

对于SAML的流程来说，用户是通过"IDP"的认证访问"SP"，而OAuth是通过"OAuth Provider"授权"OAuth Consumer"使用保存在"OAuth Provider"上的资源：

这里包含了OAuth的三方角色：End User (owns the resource that is being requested), OAuth Provider (the entity hosting the resource), OAuth Consumer (the entity requesting for resource)

简单的示例就是：以"Facebook"作为"OAuth Consumer", "Gmail"作为"OAuth Provider"，用户登录Facebook，希望将Gmail的联系人信息(即资源)导入Facebook。

具体流程解释请参见SSO Strategy: Authentication (SAML) –vs– Authorization (OAuth)

Authentication Filter

Filter是Web服务器端的概念，作为过滤Web请求的功能来使用，多用于登录验证、错误日志记录、编码转换等：在具体的实现逻辑中，指定网站页面资源匹配相应的Filter，而在Filter类内检测从Client端发来的请求是否包含指定的信息，比如session等，从而判定Client是否已经经过验证，没有的话自动转向配置好的登录页面，从而实现登录验证。

Authentication Filter作为一个过滤器，可以嫁接不同的身份认证方式，所以我们看到，在使用Authentication Filter的Mobile BI的环境中，几乎支持了所有的认证方式（参见序言部分）。使用了Authentication Filter可以分隔开认证和保护，从而使我们的认证流程更加清晰。

另外，因为Authentication Filter是作为Web Server的一部分而存在，理论上与Tomcat/IIS这些Web容器不相关，甚至与传统监听Proxy的SSO Provider不相关，理论上你可以叠加起来，当然现实实现是没有必要的。

对于Client端而言，与传统的Mobile BI不同，新的Mobile BI需要先请求指定的URL，获取Client端支持的Authentication Modes：

• 不使用Authentication Filter：支持Standard/Usher并使用RESTFul API的Login Request实现认证
• 使用Authentication Filter
  • Standard类似使用，但是需要调用不同的Login Request来获取session
  • SAML HTML Form则是在cookies中获取session

对不同的认证方式的简要流程介绍如下：

Standard/LDAP

• Application submits Login XHR request.
  • /auth/login
  • username/password/loginMode...
• The Authentication Filter authenticates user with IServer using login and password provided by the user.
• If authentication is successful the Authentication Filter returns Success response
  • Access Token in Response Header
• If authentication fails the Authenticatio Filter returns failure response
  • 401 error, login failed

SAML

• Application opens Web View with the following URL
  • ?loginMode=10***
• The filter will redirect this request to a proper SAML IDP
  • The IDP connection is configured via Spring Config XML
• The IDP engages in authentication dialog with the user.
• On successful authentication IDP redirects request to the predefined login entry point of SP.
  • This request contains SAML Assertion
• The Authentication Filter extracts user information from the SAML Assertion and submits it to IServer to create Configuration Session.
  • As minimum the user information contains user name, which is necessary to create Configuration Session in Trusted mode.
• If authentication is successful the user is redirected to the original application from first step of this workflow
• The Native application intercepts this redirect, extracts the Access Token, closes the Web View and proceeds as usual.

引用

Wikipedia SSO

Windows Authentication Overview

IIS几种身份验证方式

Wikipedia Kerberos

kerberos认证原理---讲的非常细致，易懂

Kerberos Single Sign-On in iOS

微软 Windows 系统中的 Kerberos 认证详解

Wikipedia SAML

我眼中的SAML (Security Assertion Markup Language)

SSO Strategy: Authentication (SAML) –vs– Authorization (OAuth)