Shiro 架构(上)

    对于一个好的框架，从外部来看应该 具有非常简单易于使用的 API，而且 API 契约明确；从内部来看的话，其应该有一个可扩展 的架构，即非常容易插入用户自定义实现，因为任何框架都不能满足所有需求。 
 
首先，我们从外部来看Shiro，也就是从应用程序角度的来观察如何使用Shiro完成工作。如 下图： 

 

可以看到：应用代码直接交互的对象是Subject，也就是说Shiro的对外API核心就是Subject； 其每个API的含义：

 Subject：主体，代表了当前“用户”，这个用户不一定是一个具体的人，与当前应用交互 的任何东西都是 Subject，如网络爬虫，机器人等；即一个抽象概念；所有 Subject 都绑定 到SecurityManager，与Subject的所有交互都会委托给SecurityManager；可以把Subject认 为是一个门面；SecurityManager才是实际的执行者；

 SecurityManager：安全管理器；即所有与安全有关的操作都会与 SecurityManager 交互； 且它管理着所有 Subject；可以看出它是 Shiro 的核心，它负责与后边介绍的其他组件进行 交互，如果学习过SpringMVC，你可以把它看成DispatcherServlet前端控制器； 

Realm：域，Shiro从从Realm获取安全数据（如用户、角色、权限），就是说SecurityManager 要验证用户身份，那么它需要从Realm获取相应的用户进行比较以确定用户身份是否合法；也需要从Realm得到用户相应的角色/权限进行验证用户是否能进行操作；可以把Realm看 成DataSource，即安全数据源。 
 

也就是说对于我们而言，最简单的一个Shiro应用：

1、 应用代码通过Subject来进行认证和授权，而Subject又委托给SecurityManager； 

2、 我们需要给 Shiro的 SecurityManager注入 Realm，从而让SecurityManager能得到合法 的用户及其权限进行判断。 

 
从以上也可以看出，Shiro不提供维护用户/权限，而是通过Realm让开发人员自己注入。