u

docs/download.md

@@ -1,4 +1,4 @@
-<h1>1、下载</h1>
+<h1>下载</h1>
 
 百度网盘下载
 <table border="0" class="table table-striped table-bordered ">

docs/index.md

@@ -1,4 +1,4 @@
-<h1>1、MaxKey介绍</h1>
+<h1>MaxKey介绍</h1>
 **MaxKey(马克思的钥匙)**，寓意是最大钥匙，是基于开放用户安全身份认证系统（User Security Access System）,提供简单、可靠和安全的用户认证和单点登录，包含用户认证、单点登录、资源管理、权限管理等。
 
 什么是**单点登录(Single Sign On）**，简称为**SSO**？
@@ -13,7 +13,7 @@
   
 
 
-<h2>1.1、标准化认证协议：</h2>
+<h2>标准化认证协议</h2>
 <table border="0" class="table table-striped table-bordered ">
 	<tbody>
 		<tr class="a">
@@ -65,7 +65,7 @@
 	</tbody>
 </table>
 
-<h2>1.2、登录支持</h2>
+<h2>登录支持</h2>
 
 <table border="0" class="table table-striped table-bordered ">
 	<tbody>
@@ -96,7 +96,7 @@
 	</tbody>
 </table>
 
-<h2>1.3、主要优势</h2>
+<h2>主要优势</h2>
 1. 提供标准的认证接口以便于其他应用集成SSO，安全的移动接入，安全的API、第三方认证和互联网认证的整合。
 
 2. 认证中心具有平台无关性、环境多样性，支持Web、手机、移动设备等, 如Apple iOS，Andriod等，将认证能力从B/S到移动应用全面覆盖。
@@ -107,22 +107,3 @@
 
 5. 许可证 Apache License, Version 2.0，开源免费。 
 
-<h1>2、界面</h1>
-<h2>2.1、MaxKey认证</h2>
-
-<h3>2.1.1、登录界面</h3>
-
-<img src="{{ "/images/maxkey_login.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
-
-<h3>2.1.2、主界面</h3>
-<img src="{{ "/images/maxkey_index.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
-
-<h2>2.2、MaxKey管理</h2>
-
-<h3>2.2.1、用户管理界面</h3>
-
-<img src="{{ "/images/maxkey_mgt_users.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
-
-<h3>2.2.2、应用管理界面</h3>
-
-<img src="{{ "/images/maxkey_mgt_apps.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>

docs/protocols/cas.md

@@ -1,4 +1,4 @@
-<h2>1、CAS简介</h2>
+<h2>1CAS简介</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>2、CAS体系结构</h2>
+<h2>2CAS体系结构</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>3、CAS原理</h2>
+<h2>3CAS原理</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>4、 CAS中3个术语</h2>
+<h2>4CAS中3个术语</h2>
 
 Ticket Granting ticket (TGT) ：可以认为是CAS Server根据用户名密码生成的一张票，存在Server端
 

docs/protocols/formbased.md

@@ -1,8 +1,8 @@
-<h2>1、FormBased介绍</h2>
+<h2>1FormBased介绍</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>JSON Web Token介绍</h2>
+<h2>1JSON 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>什么时候使用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>JSON Web Token结构</h2>
+<h2>3JSON 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>JSON Web Token工作机制</h2>
+<h2>4JSON Web Token工作机制</h2>
 
 在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web令牌。由于令牌是凭据，因此必须格外小心以防止安全问题。通常，令牌的保留时间不应超过要求的时间。
 
@@ -111,7 +111,7 @@ JSON Web令牌如何工作
 该应用程序使用访问令牌来访问受保护的资源（例如API）。
 请注意，使用签名的令牌，令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改它。这意味着您不应将机密信息放入令牌中。
 
-<h2>如何使用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

@@ -1,4 +1,4 @@
-<h2>1. OpenID Connect简介</h2>
+<h2>1 OpenID Connect简介</h2>
 OpenID Connect是基于OAuth 2.0规范族的可互操作的身份验证协议。它使用简单的REST / JSON消息流来实现，和之前任何一种身份认证协议相比，开发者可以轻松集成。
 
 OpenID Connect允许开发者验证跨网站和应用的用户，而无需拥有和管理密码文件。OpenID Connect允许所有类型的客户,包括基于浏览器的JavaScript和本机移动应用程序,启动登录流动和接收可验证断言对登录用户的身份。
@@ -6,12 +6,12 @@ OpenID Connect允许开发者验证跨网站和应用的用户，而无需拥有
 如果您想对OpenID Connect开放标准进行扩展阅读，请参看：官方技术说明<a href="http://openid.net/connect/"  title="http://openid.net/connect/" target="_blank" rel="nofollow">Connect标准（英文） </a> | <a href="http://en.wikipedia.org/wiki/OpenID_Connect"  title="http://en.wikipedia.org/wiki/OpenID_Connect" target="_blank" rel="nofollow">OpenID Connect维基百科（en）</a>
 
 
-<h2>2. OpenID的历史是什么？</h2>
+<h2>2 OpenID的历史是什么？</h2>
 OpenID Connect是OpenID的第三代技术。首先是原始的OpenID，它不是商业应用，但让行业领导者思考什么是可能的。OpenID 2.0设计更为完善，提供良好的安全性保证。然而，其自身存在一些设计上的局限性，最致命的是其中依赖方必须是网页，但不能是本机应用程序；此外它还要依赖XML，这些都会导致一些应用问题。
 
 OpenID Connect的目标是让更多的开发者使用，并扩大其使用范围。幸运的是，这个目标并不遥远，现在有很好的商业和开源库来帮助实现身份验证机制。
 
-<h2>3. OIDC基础</h2>
+<h2>3OIDC基础</h2>
 简要而言，OIDC是一种安全机制，用于应用连接到身份认证服务器（Identity Service）获取用户信息，并将这些信息以安全可靠的方法返回给应用。
 
 在最初，因为OpenID1/2经常和OAuth协议（一种授权协议）一起提及，所以二者经常被搞混。
@@ -28,7 +28,7 @@ OpenID Connect是“认证”和“授权”的结合，因为其基于OAuth协
 
 在OAuth中，这些授权被称为scope。OpenID-Connect也有自己特殊的scope--openid ,它必须在第一次请求“身份鉴别服务器”（Identity Provider,简称IDP）时发送过去。
 
-<h2>4. OIDC流程</h2>
+<h2>4 OIDC流程</h2>
 OAuth2提供了Access Token来解决授权第三方客户端访问受保护资源的问题；相似的，OIDC在这个基础上提供了ID Token来解决第三方客户端标识用户身份认证的问题。OIDC的核心在于在OAuth2的授权流程中，一并提供用户的身份认证信息（ID-Token）给到第三方客户端，ID-Token使用JWT格式来包装，得益于JWT（JSON Web Token）的自包含性，紧凑性以及防篡改机制，使得ID-Token可以安全的传递给第三方客户端程序并且容易被验证。应有服务器，在验证ID-Token正确只有，使用Access-Token向UserInfo的接口换取用户的更多的信息。
 
 有上述可知，OIDC是遵循OAuth协议流程，在申请Access-Token的同时，也返回了ID-Token来验证用户身份。

docs/protocols/saml.md

@@ -1,4 +1,4 @@
-<h2>1、SAML 介绍</h2>
+<h2>1SAML 介绍</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>2、SP-Init SSO流程	</h2>
+<h2>2SP-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>3、IDP-Init SSO流程</h2>
+<h2>3IDP-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>1、TokenBased介绍</h2>
+<h2>1TokenBased介绍</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>4、LTPA介绍</h2>
+<h2>4LTPA介绍</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

@@ -0,0 +1,19 @@
+<h1>界面</h1>
+<h2>MaxKey</h2>
+
+<h3>登录界面</h3>
+
+<img src="{{ "/images/maxkey_login.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}"  alt=""/>
+
+<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=""/>