Shiro 支持三种方式的授权
Subject subject = SecurityUtils.getSubject();
if(subject.hasRole(“admin”)) {
//有权限
} else {
//无权限
}
@RequiresRoles("admin")
public void hello() {
//有权限
}
三种方式背后的原理是一样的,由简单到复杂的顺序来看看。
shiro提供了RoleTag和PermissionTag的抽象类,还有两个简单的实现:
public class HasRoleTag extends RoleTag {
//TODO - complete JavaDoc
public HasRoleTag() {
}
protected boolean showTagBody(String roleName) {
return getSubject() != null && getSubject().hasRole(roleName);
}
}
public class HasPermissionTag extends PermissionTag {
//TODO - complete JavaDoc
public HasPermissionTag() {
}
protected boolean showTagBody(String p) {
return isPermitted(p);
}
}
分别调用的是DelegatingSubject的hasRole方法和isPermitted方法:
public boolean hasRole(String roleIdentifier) {
return hasPrincipals() && securityManager.hasRole(getPrincipals(), roleIdentifier);
}
public boolean isPermitted(String permission) {
return hasPrincipals() && securityManager.isPermitted(getPrincipals(), permission);
}
然后又调用AuthorizingSecurityManager的相关方法,AuthorizingSecurityManager持有一个ModularRealmAuthorizer类型的Authorizer:
this.authorizer = new ModularRealmAuthorizer();
相关方法又转移至调用ModularRealmAuthorizer:
ModularRealmAuthorizer 进行多 Realm 匹配流程:
1、首先检查相应的 Realm 是否实现了实现了 Authorizer;
2、如果实现了 Authorizer,那么接着调用其相应的 isPermitted*/hasRole*接口进行匹配;
3、如果有一个 Realm 匹配那么将返回 true,否则返回 false。
@RequiresRoles("admin")
@RequiresPermissions("admin:role:view")
@RequestMapping(value = "/configIndex", method = { RequestMethod.GET })
public String index(Model model) {
return "rolemgr/roleConfig/configIndex";
}
基于拦截器实现(AuthorizingAnnotationMethodInterceptor)
动态代理技术(CglibAopProxy)
spring InvocableHandlerMethod#invoke
CglibAopProxy.DynamicAdvisedInterceptor#intercept
AnnotationMethodInterceptor
AuthorizingAnnotationMethodInterceptor#assertAuthorized
RoleAnnotationHandler#assertAuthorized
DelegatingSubject:
public void checkRole(String role) throws AuthorizationException {
assertAuthzCheckPossible();
securityManager.checkRole(getPrincipals(), role);
}
AuthorizingSecurityManager:
public void checkRole(PrincipalCollection principals, String role) throws AuthorizationException {
this.authorizer.checkRole(principals, role);
}
ModularRealmAuthorizer:
public void checkRole(PrincipalCollection principals, String role) throws AuthorizationException {
assertRealmsConfigured();
if (!hasRole(principals, role)) {
throw new UnauthorizedException("Subject does not have role [" + role + "]");
}
}
public boolean hasRole(PrincipalCollection principals, String roleIdentifier) {
assertRealmsConfigured();
for (Realm realm : getRealms()) {
if (!(realm instanceof Authorizer)) continue;
if (((Authorizer) realm).hasRole(principals, roleIdentifier)) {
return true;
}
}
return false;
}
AuthorizingRealm:
public boolean hasRole(PrincipalCollection principal, String roleIdentifier) {
AuthorizationInfo info = getAuthorizationInfo(principal);
return hasRole(roleIdentifier, info);
}
protected boolean hasRole(String roleIdentifier, AuthorizationInfo info) {
return info != null && info.getRoles() != null && info.getRoles().contains(roleIdentifier);
}
关于 getAuthorizationInfo 方法:
protected AuthorizationInfo getAuthorizationInfo(PrincipalCollection principals) {
if (principals == null) {
return null;
}
AuthorizationInfo info = null;
Cache
private Cache
回顾下安全管理器的结构,RealmSecurityManager继承了CachingSecurityManager,当CachingSecurityManager设置了cacheManager,会调用用子类的afterCacheManagerSet方法:
public void setCacheManager(CacheManager cacheManager) {
this.cacheManager = cacheManager;
afterCacheManagerSet();
}
RealmSecurityManager将会为每个Realm设置cacheManager:
protected void afterCacheManagerSet() {
applyCacheManagerToRealms();
}
protected void applyCacheManagerToRealms() {
CacheManager cacheManager = getCacheManager();
Collection realms = getRealms();
if (cacheManager != null && realms != null && !realms.isEmpty()) {
for (Realm realm : realms) {
if (realm instanceof CacheManagerAware) {
((CacheManagerAware) realm).setCacheManager(cacheManager);
}
}
}
}
在不同层级的构造器中分别设置了是否启用权限缓存和身份验证缓存
this.authorizationCachingEnabled = true;
this.authenticationCachingEnabled = false;
再看CachingRealm,跟安全管理器的做法类似,并且为每个realm设置cacheManager的时候就已经触发了子类的相关操作:
public void setCacheManager(CacheManager cacheManager) {
this.cacheManager = cacheManager;
afterCacheManagerSet();
}
AuthorizingRealm的实现就是通过cacheManager去获取权限相关的cache:
protected void afterCacheManagerSet() {
super.afterCacheManagerSet();
//trigger obtaining the authorization cache if possible
getAvailableAuthorizationCache();
}
如果我们没有明确配置cacheManager(作为securityManager的属性注入),那么此时是获取不到的,cache为null并且启用了权限缓存,现在就要临时构造一个:
cache = getAuthorizationCacheLazy();
以principals作为key取AuthorizationInfo:
info = cache.get(key);
if (info == null) {
info = doGetAuthorizationInfo(principals);
if (info != null && cache != null) {
Object key = getAuthorizationCacheKey(principals);
cache.put(key, info);
}
}
这个时候就转到我们自己的实现了,我们自己去获取权限,然后返回一个AuthorizationInfo,就是权限相关的信息。
编程式很暴力也很直接,直接操作subject的相关方法来鉴权,其他两种方式拐弯抹角地也是操作的subject,然后再委托给securityManager。
具体是AuthorizingSecurityManager层实现的,它是直接new了一个ModularRealmAuthorizer,相关操作又转交给它,它又梳理一下,交给我们实现的realm(父类AuthorizingRealm层实现)。
ModularRealmAuthorizer是怎么获取到realm的?
也是我们给securityManager配置的,类似上面cacheManager的set方法,安全管理器用了很多这样的方法,给它本身注入相关属性时,就把相关联的set了。
AuthorizingSecurityManager这样实现的:
protected void afterRealmsSet() {
super.afterRealmsSet();
if (this.authorizer instanceof ModularRealmAuthorizer) {
((ModularRealmAuthorizer) this.authorizer).setRealms(getRealms());
}
}
从类的调用关系来看:
DelegatingSubject -> AuthorizingSecurityManager -> ModularRealmAuthorizer -> Realm
例如在自己的XxRealm中:
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
if (MySubjectUtils.isPatformAdmin()) {
simpleAuthorizationInfo.addStringPermission("*");
} else {
//查询关联的权限adminUser:create:01001001
}
}
或者在自己的权限标签中:
public class HasAnyPermissionTag extends PermissionTag {
@Override
protected boolean showTagBody(String permissions) {
boolean hasPermission = false;
Subject subject = getSubject();
if(MySubjectUtils.isPatformAdmin()){
return true;
}
//......
}
}
这样作为开发者对于角色权限的配置可以省掉了,将特定id或者name的开发人员设置为平台管理员,可以坐拥天下,在功能不断完善的情况下不需要再补充权限。