shiro 深入学习（上）

shiro 文档（中文译）提取码：us92

shiro 核心架构

• Subject(org.apache.shiro.subject.Subject)
• SecurityManager(org.apache.shiro.mgt.SecurityManager)
• Authenticator(org.apache.shiro.authc.Authenticator)
  • Authentication Strategy(org.apache.shiro.authc.pam.AuthenticationStrategy)
• Authorizer(org.apache.shiro.authz.Authorizer)
• SessionManager(org.apache.shiro.session.SessionManager)
  • SessionDAO(org.apache.shiro.session.mgt.eis.SessionDAO)
• CacheManager(org.apahce.shiro.cache.CacheManager)
• Cryptography(org.apache.shiro.crypto.*)
• Realms(org.apache.shiro.realm.Realm)

（这些名词就不解释了，可以从上方的文档中知晓）

---

The SecurityManager

Shiro 鼓励以Subject为中心的编程方式。即便如此，了解如何 SecurityManager 是如何工作的仍然重要，尤其在为应用程序配置一个 SecurityManager 的时候。

(SecurityManager 的工作：1、执行安全操作;2、管理所有用户的安全状态)

设计 SecurityManager

SecurityManager 默认可以做很多事情：

• Authentication
• Authorization
• Session Management
• Cache Management
• Realm coordination
• Event propagation
• “Remember Me” Services
• Subject creation
• Logout
• …

然而，把这些功能全部都添加到 SecurityManager 中，又想它们被灵活地使用，这是很困难的。

为了简化配置，并提高灵活性，Shiro SecurityManager 的实现是高度模块化设计：SecurityManager （以及它的类层次结构）并没有做很多事情，相反，SecurityManager 的实现主要是作为一个轻量级的 “容器” 组件，委托所有的行为被嵌套/包裹到其它小组件。这种“包装”的设计体现在上面的详细构架图。
实际执行组件时，SecurityManager 知道何时并如何协调组件来完成正确的行为。

SecurityManager 实现和组件都是兼容 JavaBean 的，它允许你（或某个配置机制）通过标准的 JavaBean 的 accessor/mutator 方法（get*/set*）轻松地自定义可拔插组件。这意味着 Shiro 的架构的组件性能够把自定义行为转 化为非常容易的配置文件。

---

shiro 配置

直接编程配置

Realm realm = //instantiate or acquire a Realm instance. We' 11 discuss Realms later.
SecurityManager securityManager = new DefaultSecurityManager (realm);
//Make the SecurityManager instance available to the entire application via static memory.
SecurityUtils.setSecurityManager(securityManager);

Shiro 的 SecurityManager 实现实质上是一个特定安全的嵌套组件中的模块化 对象图。因为它们也是兼容 JavaBean 的，你可以调用任何嵌套组件的 getter 和 setter 方法来配置 SecurityManager 以及它的内部对象图。
例如，如果你想配置 SecurityManager 实例来使用自定义的 SessionDAO 来定制 Session Management，你可以通过嵌 套的 SessionManager 的 setSessionDAO 方法直接设置 SessionDAO：

...
DefaultSecurityManager securityManager = new DefaultSecurityManager(realm);
SessionDAO sessionDAO = new CustomSessionDA0();
((DefaultSessionManager)securityManager.getSessionManager()).setSessionDAO(sessionDAO);
...

ini 文件配置

略
（文档里详细说明）

---

身份验证（Authentication）

Authentication 是指身份验证的过程 —— 即证明一个用户是不是他们所说的“那个谁”。
通过提交用户的身份（principal）和凭证（credentials）给 Shiro，以判断它们是否和应用程序预期的相匹配。

Authenticating Subjects

验证 Subjects 的过程中，可以有效地分解成三个不同的步骤：

1. 收集 Subjects 提交的 Principals(身份)和 Credentials(凭证)；
2. 提交 Principals(身份)和 Credentials(凭证)进行身份验证；
3. 如果提交成功，则允许访问，否则重新进行身份验证或者阻止访问。

step 1：收集 Subject 的 Principals(身份)和 Credentials(凭证)

 UsernamePasswordToken token = new UsernamePasswordToken(username, password); 

使用 UsernamePasswordToken 来支持最常见的用户名/密码的身份验证方法。这是 Shiro的 org.apache.shiro.authc.AuthenticationToken 的接口，是Shiro代表提交的Principals(身份)和Credentials(凭 证)的身份验证系统所使用的基本接口的一个实现。

Step 2：提交 Subject 的 Principals(身份)和 Credentials(凭证)

//获取当前正在执行操作的 subject
Subject currentUser = SecurityUtils.getSubject();  
//提交 principal 和 credential
currentUser.login(token);  
token.setRememberMe(true); 

实例化 AuthenticationToken 后，提交给 Shiro 执行真正的身份验证；捕获到当前执行的 Subject 后，调用单一的 login 方法，并将之前的 AuthenticationToken 实例传递给它。
通过调用 login 方法，进行身份验证。

Step3：处理成功或失败

//isAuthenticated() 判断 currentUser 是否已经被认证
if(!currentUser.isAuthenticated()){
     try{
         currentUser.login(token);
       //当前账户不存在
     } catch(UnknownAccountException unknownAccountExecption){
       //提供的证书（密码）错误
     } catch(IncorrectCredentialsException incorrectCredentialsException){
       //该账户被锁定
     } catch(LockedAccountException lockedAccountException){
     }
     // ........
     //捕获其他可能出现的错误，当然异常类可以是自己实现的
 }

login 方法平静地返回 —— 该 Subject 已通过验证，应用程序线程继续下去。
未通过认证，捕捉任何你期望的异常并进行相应的反应（Shiro 拥有丰富的运行时 AuthenticationException 层次结构，可以指出尝试失败的确切原因）。

Step4：注销

currentUser.logout();

调用 logout，释放当前 Subject 所有已知的的识别状态：

• 任何现有的 Session 都将会失效
• 任何身份都将会失去关联（例如，在 Web 应用程序 中，RememberMe cookie 也将被删除）。

web 应用应该注意： Web 应用程序依靠 Cookies记住身份信息，然而 Cookies 只能在 Response 被 committed 之前被删除，所以强烈建议在调用 subject.logout()后立即将终端用户重定向到一个新的视图或页面。 这样能够保证任何与安全相关的Cookies都能像预期的一样被删除。这是HTTP cookies的功能限制，而不是Shiro 的。

验证顺序

---

博客指路：
shiro 深入学习（下）
目录