安全认证是计算中科学中重要的一部分，主要分为：
系统层次；
网络层次；
更高层次：
一、系统层次
访问一个设备时，我们需要验证身份，通常有以下几种：
- 无任何验证（无密码等……）；
- 用户名；
- 密码；
- 加密信息；
- 生物学信息（指纹，面部等）；
- 行为分析（声音，签名，动态输入）。
举例：
Shadow password(Unix)
登录Linux时会要求输入用户名和密码。通常本地文件中会存储一份用户密码，并与用户输入对比，如果相同就允许用户登录。起初用户密码存储于/etc/passwd中，但由于/etc/passwd必须供所有用户读取，因此为避免密码破译，Unix系统将加密后的密码存储于/etc/shadow中，仅供超级用户可读（大型站点中使用NIS、LDAP、NIS+等方式存储）。
SHA (Secure Hash Algorithm，译作安全散列算法)
我们在别的章节介绍过
PAM
Pluggable Authentication Modules (modules d’authentification enfichables)，
Encapsulation de mécanismes d’authentification 认证机制的封装
将那些认证方法植入应用之中。
/etc/pam.conf
/etc/pam.d
man PAM
二、网络层次
Radius 认证协议介绍
引用自：https://blog.byneil.com/radius-认证协议介绍/
1. 定义：
维基: 远端用户拨入验证服务（RADIUS, Remote Authentication Dial In User Service）是一个AAA协议，意思就是同时兼顾验证（authentication）、授权（authorization）及计费（accounting）三种服务的一种网络传输协议（protocol），通常用于网络存取、或流动IP服务，适用于局域网及漫游服务。例如, 宽带 ADSL 拨号上网的后台认证和计费系统就可以用radius, 或者 V-P-N 系统的后台验证计费系统就是radius 的使用场景.
https://zh.wikipedia.org/wiki/RADIUS
2. Radius 的工作方式
图中有三个部分： Radius服务器， VPN服务器，客户端。
VPN服务器相当于Radius服务器的client。
1) 首先, radius 是基于udp的协议, 所有数据包都是封装在udp协议中.
至于为什么是udp,而不是tcp, 请参看 rfc 的解释: Why udp?
2) radius 协议包的格式.
基本上, radius 协议有四种包：
Access-Request
Access-Accept
Access-Reject
Access-Challenge
这四种包在 VPN服务器和radius 服务器之间通信,来完成整个过程.
图中, 前面三个交互是必须的, 后面两个绿色的带星号的交互不是必须的.
首先, xxx 服务器向radius发送 Access-Request 数据包, 包含用户信息和密码哈希等等信息用于认证.
此时服务器有四个选择:
第一, 如果认证通过,就返回一个 "Access-Accept" 数据包, 认证完成.
第二, 如果认证不通过,则返回 "Access-Reject",认证失败.
第三, 如果服务器认为必要, 可以返回一个"Access-Challenge" 数据包, 让用户提供更多的附加信息以完成认证. 而xxx服务器在收到 "Access-Challenge" 消息之后, 需要向用户索要必须的附加信息,然后组成一个新的 " Access-Request" 数据包发给radius服务器来继续认证. 此时服务器可以重复第一,或第二.
第四, 如果 "Access-Request" 数据包有问题, 服务器还可以采取 "静默丢弃"(silently discard) 的方式, 不做任何反应.
这就是主要的通信流程了.
一般来讲, 作为 radius 的客户端, "Access-Request" 数据包的格式比较重要. 他负责将认证信息加密传输给radius 服务器.
Kerberos
引用自：https://blog.csdn.net/kkdelta/article/details/46633557 （非常清晰）
白话总结：
client 要访问 server，需经过KDS的验证和授权。 KDS是cilent 和server信任的第三方。client和KDS之间，KDS和server之间都有各自独立的，私密的沟通。 首先，client想要访问server需向kds证明自己的身份，提供自己的信息，验证通过后，生成一个ticket，KDS用KDS和client 之间的密钥加密该ticket发给client，client解密得到ticket（此过程也是client验证KDS的身份）；之后Client再拿着ticket问KDS要server ticket，这个是server认的票。KDS就把关于client的信息+server ticket 首先用KDS和server之间的密钥加密，再用KDS和Client之间的密钥加密发给client，以确保Client不会看到不该看的部分。然后让client把这些“推荐信，证明信”解密后，转发给server。server收到后，用server和KDS的密钥解密，看到可靠的KDS亲笔写的证明信，server便可用允许client访问了。（不放心的同学请往下看——非白话版）
原理：
Kerberos 服务是单点登录系统，这意味着您对于每个会话只需向服务进行一次自我验证，即可自动保护该会话过程中所有后续事务的安全。服务对您进行验证后，即无需在每次使用基于 Kerberos 的服务时进行验证。因此，无需在每次使用这些服务时都在网络上发送口令（增强了安全性）。MIT写了一段故事型的对话，比较生动得表述了Kerberos协议的工作原理：
Athena和欧里庇得斯关于地狱之门守护者的对话。简而言之，kerbores V5的工作原理如下：
Kerbores中有三种角色：
KDC：负责分发密钥的密钥分配中心
Client：需要使用kerbores服务的客户端
Service：提供具体服务的服务端
其中，Client需要和KDC和Service都进行通信。协议授权流程分两个部分：
(1) 获取原始票据
首先，Client向KDC发送自己的身份信息，KDC从授予票据服务(Ticket Granting Service)得到可用的票据(ticket-granting ticket)，并用协议开始前KDC与Client之间的密钥将票据加密回复给client，client收到KDC回复的加密票据后利用与client先前协议的密钥将票据解密，从而获得票据，此步骤主要是允许client进行Kerberos的验证，是进行访问服务的先决条件。
(2) 获取服务票据以及访问服务
client利用之前获得的票据向KDC请求服务票据，从而通过服务的身份验证。获取服务票据以及访问服务总共有如下四步：
①. client将之前获得的票据和要请求的服务信息发送给KDC，KDC中的授予票据服务将client和service之间生成一个会话密钥(Session Key)用于服务器与client的身份验证。然后KDC将这个会话密钥和用户名，用户地址(IP)，服务名，有效期，时间戳一起包装成一个票据(这张票据用于service对client的身份验证)通过client转发给service。
②. 为了让票据对client保密，所以KDC用协议开始之前KDC与服务端之间的密钥将票据加密后再发给client，同时为了让client与service之间共享那个会话密钥，KDC用client与它之间的密钥将会话密钥加密返回给client
③. 为了完成票据的传递，client将刚才收到的票据转发到service，由于client不知道KDC与service的密钥，所以它无法修改票据的信息，同时client将收到的会话密钥解压出来，然后将自己的用户名，用户地址(IP)打包成验证包用会话密钥加密也发给service
④. Service收到票据后利用它与KDC之间的密钥将票据中的信息解密出来，从而获得会话密钥和用户名，用户地址(IP)，服务名，有效期。然后再用会话密钥将验证包解密从而获得用户名，用户地址(IP)将其与之前票据中解密出来的用户名，用户地址(IP)做比较从而验证client的身份，如果service有返回结果，将其返回给client.
三、更高层次
CAS
Central Authentication Service – CAS 中央认证服务。CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法。CAS Server负责完成对用户的认证工作 ，会为用户签发两个重要的票据：登录票据（TGT）和服务票据（ST）来实现认证过程, CAS Server需要独立部署 。
原理
从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。
CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份核实，以确保 Service Ticket 的合法性。
SSO
认识SSO：
Single Sign On，单点登录。SSO是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的企业业务整合的解决方案之一。
SSO的作用：
当我们第一次访问一个应用系统时，还没有登录，系统会引导我们去认证系统中登录（参见上面CAS），根据我们提供的信息进行校验（与我们存储在认证系统中的信息进行比对），一旦登陆成功，我们会得到一个认证凭证——一个ticket。我们再访问别的应用的时候就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
SSO的实现基础：
- 统一认证系统，统一ticket的产生和校验（多个应用系统请求的认证系统应当是共享的，由此才能从不同终端登录都能得到相同的、大家都承认的ticket，在后续再次验证时才能够顺利通过）；
- 应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过
OpenID/OAuth
引用：https://blog.csdn.net/cxzhq2002/article/details/78856730
Oauth、openID、SAML是身份身份认证授权的规范和标准，是解决认证授权问题的。
OpenID与Oauth协议的区别，可以从其标准定义的核心应用场景来分析：
1） Oauth协议的使用场景：用户通过第三方照片打印应用打印在某个网站存储的照片，而不希望泄露照片网站的用户名、密码等信息给第三方的照片打印应用。
2） OpenID协议的使用场景，用户在多个网站注册，需要注册并记住多个用户名密码，openid希望帮用户提供一个身份ID，可以在多个网站用来登录。登录网站时，用户选择用其身份ID登录，跳转到身份ID颁发的网站输入用户名、密码进行身份认证，然后跳转会网站实现登录。即我们当前很多时候看到的用”QQ帐号登录”、“微信帐号登录”等。
所以我们可以总结，两个协议的核心区别：
1）Oauth协议的认证凭证必须是资源拥有者发放的；而OpenID的认证凭证可以是你需要登录的网站支持的其它任何正规Openid Provier网站均可。
2）OpenID只是身份的象征，可以看作是身份证；而Oauth认证凭证，一定是资源拥有者发放的，不仅是用户在资源拥有者系统身份的凭证，还是其某些授权资源访问的凭证，可以看作是钥匙。
SAML支持XACML协议进行权限控制。SAML协议较OAUTH来说确实比较复杂，但是功能也十分强大，支持认证，权限控制和用户属性。
进一步，我们开发时候，如果是单系统身份认证，根据使用场景和技术特点，选择OpenID、Oauth、或者SAML。如果不是单系统，不仅涉及身份认证，而是涉及众多系统需要单点登录，则需要选择CAS+认证方案(OpenID/Oauth/SAML)来实现的。
SSO（CAS）与认证服务标准是合作而不是排斥的关系
Shibboleth
引用：http://lhy5201314.iteye.com/blog/1171266（推荐）
Shibboleth 有两个主要的部分，一个是身份提供商（ IDP ， identity provider ），另外一个是服务提供商（SP ， service provider ）。身份提供者（ IDP ）提供信息的服务用户，服务供应商（ SP ）收集有关用户的信息，以保护资源。一个典型的例子， Web 浏览器访问一个受保护的资源，在他们的身份提供商（ IDP ）进行身份验证，并最终返回在受保护资源处重新登录。