u

docs/_includes/navigation.html

@@ -3,7 +3,13 @@
 		<ul class="nav nav-list">
 			<li class="nav-header"><img class="imageLink" src="{{ "/images/home.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}" alt="Apache Log4j™ 2" border="0"/> MaxKey</li>
 			<li class=""><a href="{{site.baseurl}}/index.html"><span class="none"></span>About关于</a></li>
-			<li class=""><a href="{{site.baseurl}}/ui.html"><span class="none"></span>UI用户界面</a></li>
+			<li class="">
+				<a href="#"><span class="icon-chevron-down"></span>UI用户界面</a>
+				<ul class="nav nav-list">
+					<li class=""><a href="{{site.baseurl}}/ui.html"><span class="none"></span>MaxKey界面</a></li>
+					<li class=""><a href="{{site.baseurl}}/ui_mgt.html"><span class="none"></span>管理界面</a></li>
+				</ul>
+			</li>
 			<li class="">
 				<a href="#"><span class="icon-chevron-down"></span>认证协议</a>
 				<ul class="nav nav-list">

docs/protocols/cas.md

@@ -1,4 +1,4 @@
-<h2>1CAS简介</h2>
+<h2>1 CAS简介</h2>
 
 CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：
 
@@ -15,12 +15,12 @@ CAS的目标是允许用户访问多个应用程序只提供一次用户凭据
 
 如果您想对CAS进行扩展阅读，请参看：官方技术说明<a href="https://www.apereo.org/cas"  title="https://www.apereo.org/cas" target="_blank" rel="nofollow">CAS官方网站（en） </a> | <a href="http://en.wikipedia.org/wiki/Central_Authentication_Service"  title="http://en.wikipedia.org/wiki/Central_Authentication_Service" target="_blank" rel="nofollow">CAS维基百科（en）</a> 
 
-<h2>2CAS体系结构</h2>
+<h2>2 CAS体系结构</h2>
 CAS 体系包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。
 
 <img src="{{ "/images/cas/1.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
 
-<h2>3CAS原理</h2>
+<h2>3 CAS原理</h2>
 CAS 最基本的协议过程：
 
 <img src="{{ "/images/cas/2.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
@@ -45,7 +45,7 @@ CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保
 
 另外，CAS 协议中还提供了 Proxy （代理）模式，以适应更加高级、复杂的应用场景，具体介绍可以参考 CAS 官方网站上的相关文档。
 
-<h2>4CAS中3个术语</h2>
+<h2>4 CAS中3个术语</h2>
 
 Ticket Granting ticket (TGT) ：可以认为是CAS Server根据用户名密码生成的一张票，存在Server端
 

docs/protocols/formbased.md

@@ -1,8 +1,8 @@
-<h2>1FormBased介绍</h2>
+<h2>1 FormBased介绍</h2>
    
 HTTP+HTML FormBased(基于表单)的认证，目前一般简单的基于表单的认证，是一种登录技术，即一个网站使用一个Web表单收集，并随后进行身份验证；认证的凭证信息来源于用户代理，通常web浏览器。 （请注意，短语“基于表单的认证”是不明确的。请参阅进一步解释基于表单的认证。）
 
-<h2>2交互概要</h2>
+<h2>2 交互概要</h2>
  
 该技术的实现步骤是：
  <ol>
@@ -13,21 +13,21 @@ HTTP+HTML FormBased(基于表单)的认证，目前一般简单的基于表单
   <li>网站实现中，Web服务器上运行时，执行对网络的形式的数据部分的验证和确认操作。如果成功，该网站考虑用户代理进行认证。</li>
 </ol>
 
-<h2>3采纳建议</h2>
+<h2>3 采纳建议</h2>
 
 HTTP + HTML基于表单的认证，可以说是万维网上采用当今最流行的用户认证技术。几乎所有维基，论坛，银行/财经网站，电子商务网站，网络搜索引擎，门户网站，和其他常见的Web服务器应用程序都选择了这种认证技术。
 
 
 这种普及显然是由于网站管理员或他们的雇主想要细粒度地控制征求用户凭据的表现和行为，而默认弹出对话框（用于HTTP基本访问身份验证或摘要接入认证），许多Web浏览器提供不允许精确的剪裁。所需的精确度可以通过公司的要求（如品牌）或实施问题的动机（如网站之类的软件对于MediaWiki，phpBB的，Drupal的，WordPress的默认配置）。无论理由，任何企业品牌或用户体验的调整不能从这个认证过程的几个安全考虑分散。
 
-<h2>4.安全方面注意事项</h2>
+<h2>4 安全方面注意事项</h2>
  <ol>
   <li>用户凭据传递了密文到web网站，除非采取诸如就业传输层安全（TLS）的监听。</li>
   <li>该技术基本上是特设在于有效地没有任何用户代理和所述网络服务器之间的交互，除HTTP之外的与HTML本身是标准化。通过该网站所使用的实际的认证机制是，默认，未知的用户和用户代理。形式本身，包括可编辑字段的数量，和期望的内容物，完全实现和部署相关的。</li>
   <li>这种技术本身临时的，否则犯罪分子极易伪装成可信任方在认证过程中。</li>
 </ol>
 
-<h2>5代码实现</h2>
+<h2>5 代码实现</h2>
 <pre><code class="html hljs">
 &lt;form method="post" action="/login"&gt;
   &lt;input type="text" name="username" required&gt;

docs/protocols/jwtintros.md

@@ -1,10 +1,10 @@
-<h2>1JSON Web Token介绍</h2>
+<h2>1 JSON Web Token介绍</h2>
 
 JSON Web Token （JWT）是一个开放标准（<a href="https://tools.ietf.org/html/rfc7519" target="_blank">RFC 7519</a>），它定义了一种紧凑且自包含的方式，用于在各方之间安全地将信息作为JSON对象传输。由于此信息是经过数字签名的，因此可以被验证和信任。可以使用秘密（使用<b>HMAC</b>算法）或使用<b>RSA</b>或<b>ECDSA</b>的公用/专用密钥对对JWT进行签名。
 
 尽管可以对JWT进行加密以在各方之间提供保密性，但我们将重点关注已签名的令牌。签名的令牌可以验证其中包含的声明的完整性，而加密的令牌则将这些声明隐藏在其他方的面前。当使用公钥/私钥对对令牌进行签名时，签名还证明只有持有私钥的一方才是对其进行签名的一方。
 
-<h2>2什么时候使用JSON Web Token</h2>
+<h2>2 什么时候使用JSON Web Token</h2>
 
 以下是JSON Web令牌有用的一些情况：
 
@@ -12,7 +12,7 @@ JSON Web Token （JWT）是一个开放标准（<a href="https://tools.ietf.org/
 
 <b>信息交换：</b>JSON Web令牌是在各方之间安全地传输信息的好方法。因为可以对JWT进行签名（例如，使用公钥/私钥对），所以您可以确定发件人是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此您还可以验证内容是否遭到篡改。
 
-<h2>3JSON Web Token结构</h2>
+<h2>3 JSON Web Token结构</h2>
 
 JSON Web Token以紧凑的形式由三部分组成，这些部分由点（.）分隔，分别是：
 
@@ -88,7 +88,7 @@ HMACSHA256(
 <img src="{{ "/images/jwt/legacy-app-auth-5.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
 
 
-<h2>4JSON Web Token工作机制</h2>
+<h2>4 JSON Web Token工作机制</h2>
 
 在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web令牌。由于令牌是凭据，因此必须格外小心以防止安全问题。通常，令牌的保留时间不应超过要求的时间。
 
@@ -111,7 +111,7 @@ JSON Web令牌如何工作
 该应用程序使用访问令牌来访问受保护的资源（例如API）。
 请注意，使用签名的令牌，令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改它。这意味着您不应将机密信息放入令牌中。
 
-<h2>5如何使用JSON Web Token</h2>
+<h2>5 如何使用JSON Web Token</h2>
 
 让我们谈谈与Simple Web Tokens（SWT）和Security Assertion Markup Language Tokens安全性声明标记语言令牌（SAML）相比，JSON Web Tokens（JWT）的优势。
 

docs/protocols/oauth2.md

@@ -1,4 +1,4 @@
-<h2>1什么是OAuth2</h2>
+<h2>1 什么是OAuth2</h2>
 
 OAuth： OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。
 
@@ -10,7 +10,7 @@ Tips：
 
 如果您想对OAuth2.0开放标准进行扩展阅读，请参看：<a href="http://oauth.net/2/" target="_blank">OAuth标准（英文）</a> | <a href="http://zh.wikipedia.org/zh/OAuth"  target="_blank">OAuth维基百科（中文）</a>
 
-<h2>2应用场景</h2>
+<h2>2 应用场景</h2>
 
 第三方应用授权登录：在APP或者网页接入一些第三方应用时，时长会需要用户登录另一个合作平台，比如QQ，微博，微信的授权登录。
 <img src="{{ "/images/oauth2/qq.jpg" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
@@ -19,7 +19,7 @@ Tips：
 
 前后端分离单页面应用（spa）：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证，比如使用vue、react后者h5开发的app。
 
-<h2>3名词定义</h2>
+<h2>3 名词定义</h2>
 
 （1） Third-party application：第三方应用程序，本文中又称"客户端"（client），比如打开知乎，使用第三方登录，选择qq登录，这时候知乎就是客户端。
 
@@ -33,7 +33,7 @@ Tips：
 
 （6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
 
-<h2>4运行流程</h2>
+<h2>4 运行流程</h2>
 
 <img src="{{ "/images/oauth2/flow.jpg" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
 
@@ -49,7 +49,7 @@ Tips：
 
 （F）资源服务器确认令牌无误，同意向客户端开放资源。
 
-<h2>5四种授权模式</h2>
+<h2>5 四种授权模式</h2>
 
 授权码模式（authorization code）
 
@@ -59,7 +59,7 @@ Tips：
 
 客户端模式（client credentials）
 
-<h3>5.1授权码模式</h3>
+<h3>5.1 授权码模式</h3>
 
 授权码模式（authorization code）是功能最完整、流程最严密的授权模式。
 <img src="{{ "/images/oauth2/code.jpg" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
@@ -71,7 +71,7 @@ Tips：
 （3）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。POST /oauth/token?response_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=重定向页面链接。请求成功返回access Token和refresh Token。
 
 
-<h3>5.2简化模式Implicit</h3>
+<h3>5.2 简化模式Implicit</h3>
 
 适用于公开的浏览器单页应用
 <img src="{{ "/images/oauth2/implicit.jpg" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
@@ -85,7 +85,7 @@ Access Token直接从授权服务器返回(只有前端渠道)
 最容易受安全攻击
 
 
-<h3>5.3用户名密码 Resource Owner Credentials</h3>
+<h3>5.3 用户名密码 Resource Owner Credentials</h3>
 <img src="{{ "/images/oauth2/resource.jpg" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
 
 使用用户名密码登录的应用，例如桌面App
@@ -97,7 +97,7 @@ Access Token直接从授权服务器返回(只有前端渠道)
 假定资源拥有者和公开客户子啊相同设备上
 
 
-<h3>5.4客户端凭证 Client Credentials</h3>
+<h3>5.4 客户端凭证 Client Credentials</h3>
 <img src="{{ "/images/oauth2/client.jpg" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
 
 适用于服务器见通信场景，机密客户代表它自己或者一个用户

docs/protocols/openid.md

@@ -11,7 +11,7 @@ OpenID Connect是OpenID的第三代技术。首先是原始的OpenID，它不是
 
 OpenID Connect的目标是让更多的开发者使用，并扩大其使用范围。幸运的是，这个目标并不遥远，现在有很好的商业和开源库来帮助实现身份验证机制。
 
-<h2>3OIDC基础</h2>
+<h2>3 OIDC基础</h2>
 简要而言，OIDC是一种安全机制，用于应用连接到身份认证服务器（Identity Service）获取用户信息，并将这些信息以安全可靠的方法返回给应用。
 
 在最初，因为OpenID1/2经常和OAuth协议（一种授权协议）一起提及，所以二者经常被搞混。

docs/protocols/saml.md

@@ -1,4 +1,4 @@
-<h2>1SAML 介绍</h2>
+<h2>1 SAML 介绍</h2>
  	
 SAML即安全断言标记语言，英文全称是Security Assertion Markup Language。它是一个基于XML的标准，用于在不同的安全域(security domain)之间用户身份验证和授权数据交换。在SAML标准定义了身份提供者(identity provider)和服务提供者(service provider)，这两者构成了前面所说的不同的安全域。 SAML是OASIS组织安全服务技术委员会(Security Services Technical Committee)的产品。官方技术说明可参看OASIS Security Services (SAML) TC.
     
@@ -48,7 +48,7 @@ IDP和SP预先完成证书的互信配置，SAML认证基于断言，断言基
 
 如果您想对SAML 2.0开放标准进行扩展阅读，请参看：官方技术说明<a href="https://wiki.oasis-open.org/security/FrontPage"  title="https://wiki.oasis-open.org/security/FrontPage" target="_blank" rel="nofollow">SAML标准（英文） </a> | <a href="http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language"  title="http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language" target="_blank" rel="nofollow">SAML维基百科（中文）</a> 
 
-<h2>2SP-Init SSO流程	</h2>
+<h2>2 SP-Init SSO流程	</h2>
 <img src="{{ "/images/saml/saml2.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
 
 用户试图访问IDP的合作伙伴应用。
@@ -69,7 +69,7 @@ IDP SAML响应和RelayState参数进行编码，并将该信息返回到用户
 
 用户被重定向的目标URL，并记录在合作伙伴应用程序。
 
-<h2>3IDP-Init SSO流程</h2>
+<h2>3 IDP-Init SSO流程</h2>
 <img src="{{ "/images/saml/saml3.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
 
 IDP的用户进行身份验证。IDP可以通过要求有效的登录凭据，或通过检查有效的会话对用户进行身份验证。

docs/protocols/tokenbased.md

@@ -1,8 +1,8 @@
-<h2>1TokenBased介绍</h2>
+<h2>1 TokenBased介绍</h2>
 
 TokenBased(基于令牌)的认证，是一种简单的令牌的认证，即认证中心和应用共享凭证或者数字证书，认证中心使用HTTP POST的方式提交令牌到应用系统，应用系统并随后进行身份验证；
 
-<h2>2交互概要</h2>
+<h2>2 交互概要</h2>
  
 该技术的实现步骤是：
  <ol>
@@ -14,14 +14,14 @@ TokenBased(基于令牌)的认证，是一种简单的令牌的认证，即认
   <li>应用系统完成系统登录。</li>
 </ol>
 
-<h3>2.1令牌加密或者签名方式</h3>
+<h3>2.1 令牌加密或者签名方式</h3>
 
 <ol>
   <li>加密方式：DES、DESede、AES、Blowfish，默认采用DES。</li>
   <li>签名方式：服务端使用RSA数字证书私钥加密，客户端使用RSA数字证书公钥验证。</li>
 </ol>
 
-<h3>2.2令牌格式</h3>
+<h3>2.2 令牌格式</h3>
 
 <pre><code class="json hljs">
 {
@@ -44,13 +44,13 @@ at是当前认证的时间<br>
 expires是过期的间隔<br>
 其他的字段可在管理控制台配置
 
-<h2>3简单令牌</h2>
+<h2>3 简单令牌</h2>
 
 认证用户名@@认证时间(UTC时间),例如：
 <pre class="prettyprint">
 testUser@2010-01-01T01:01:01.001Z
 </pre>
-<h3>3.1令牌加密</h3>
+<h3>3.1 令牌加密</h3>
 
 加密步骤：
  <ol>
@@ -64,20 +64,20 @@ testUser@2010-01-01T01:01:01.001Z
 <pre class="prettyprint">
 Y00jv2TCCuk365uB2-nDCUdboygeYFoUfETC7BNXr73dQWwFNRrfYltczDQ5iWg8NTO-GsP--VlR6L-JyNhZSg
 </pre>
-<h3>3.2令牌签名</h3>
+<h3>3.2 令牌签名</h3>
 
 token的签名格式：BASE64URL(UTF8(data)).BASE64URL(UTF8(signature))，中间用"<em style='font-size: 30px;  font-style: normal;'>.</em>"分开，前半部分是数据，后半部分是签名书数据，例如：<br>
 <pre class="prettyprint">
 eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ<em style="font-size: 40px;  font-style: normal;">.</em>dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
 </pre>
 
-<h2>4LTPA介绍</h2>
+<h2>4 LTPA介绍</h2>
     
 LTPA是Lightweight ThirdParty Authentication简称，轻量级第三方认证，支持在一个因特网域中的一组 Web 服务器之间使用单一登录的认证框架，即通过cookie来传输Token。
 
 当服务器配置LTPA认证方式，用户通过浏览器成功登录，服务器会自动发送一个session cookie给浏览器，此cookie中包含一个加密和签名Security Token信息，应用服务器根据Security Token解析得到登录用户信息自动完成应用系统认证。
 
-<h3>4.1交互概要</h3>
+<h3>4.1 交互概要</h3>
  
  该技术的实现步骤是：
  <ol>

docs/ui.md

@@ -1,5 +1,4 @@
-<h1>界面</h1>
-<h2>MaxKey</h2>
+<h1>MaxKey界面</h1>
 
 <h3>登录界面</h3>
 
@@ -7,13 +6,3 @@
 
 <h3>主界面</h3>
 <img src="{{ "/images/maxkey_index.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
-
-<h2>MaxKey管理界面</h2>
-
-<h3>用户管理界面</h3>
-
-<img src="{{ "/images/maxkey_mgt_users.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
-
-<h3>应用管理界面</h3>
-
-<img src="{{ "/images/maxkey_mgt_apps.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>

docs/ui_mgt.md

@@ -0,0 +1,9 @@
+<h2>MaxKey管理界面</h2>
+
+<h3>用户管理界面</h3>
+
+<img src="{{ "/images/maxkey_mgt_users.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
+
+<h3>应用管理界面</h3>
+
+<img src="{{ "/images/maxkey_mgt_apps.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>