shiro实现APP、web统一登录认证和权限管理

先说下背景,项目包含一个管理系统(web)和门户网站(web),还有一个手机APP(包括Android和IOS),三个系统共用一个后端,在后端使用shiro进行登录认证和权限控制。好的,那么问题来了web和APP都可以用shiro认证吗?两者有什么区别?如果可以,解决方案是什么?看着大家焦急的小眼神,接下来挨个解决上面的问题。

web和APP可以用shiro统一登录认证吗?

可以。假如web和APP都使用密码登录的话,那没的说肯定是可以的,因为对于shiro(在此不会介绍shiro详细知识,只介绍本文章必要的)来说,不管是谁登录,用什么登录(用户名密码、验证码),只要通过subject.login(token)中的token告诉shiro,然后在自己定义的Realm里面给出自己的认证字段就可以了,好吧说的云里雾里,看看代码

// 在自己登录的rest里面写,比如UserRest里面的login方法中,user为传递过来的参数
Subject currentUser = SecurityUtils.getSubject();
UsernamePasswordToken token = new UsernamePasswordToken(user.getUserName(), user.getPassword());
// 开始进入shiro的认证流程
currentUser.login(token);

上面的代码是开始使用shiro认证,调用subject.login(token)之后就交给shiro去认证了,接下来和我们相关的就是自定认证的Realm了,比如自定义UserRealm

protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken authcToken) throws AuthenticationException {
        //获取基于用户名和密码的令牌
        //实际上这个token是从UserResource面currentUser.login(token)传过来的
        //两个token的引用都是一样的
        UsernamePasswordToken token = (UsernamePasswordToken)authcToken;
        System.out.println("验证当前Subject时获取到token为" + ReflectionToStringBuilder.toString(token, ToStringStyle.MULTI_LINE_STYLE));
        // 从数据库中获取还用户名对应的user
        User user = userService.getByPhoneNum(token.getUsername());
        if(null != user){
            AuthenticationInfo authcInfo = new SimpleAuthenticationInfo(user.getPhoneNum(),user.getPassword(), getName());
            return authcInfo;
        }else{
            return null;
        }
    }  

再配一张图

图中描述的是使用shiro进行一个完整的登录过程

所以由以上代码看出目前我们还没有发现APP和web登录d区别,那么区别是什么呢?

web和APP登录认证的区别

好吧,标题不太准确,应该是登录的时候和登陆之后会话保持在web和APP之间的区别,先说登录:

登录

APP和PC web所需的设备不同很大程度上决定了两者之间的区别,web一般在PC上浏览,登录的时候使用用户名和密码,如果使用了记住密码就是用cookie认证,web登录有以下情况

  • 第一次登录,使用用户名和密码登录
  • 关闭浏览器、session过期,重新使用密码登录(如果有记住密码功能,可以使用cookie登录)
  • 用户删除cookie或者cookie过期,使用户名和密码登录

APP在移动设备上查看,第一次登录的时候使用用户名和密码,但是以后如果不是用户主动退出,都应该保持登录状态,这样才会有更好的用户体验,但是不可能一直保留该APP的会话,也不可能把密码保存在本地,所以APP应该以下的过程

  • 第一次登录,使用用户名密码
  • 以后用户打开应用之后,用户不需输入密码系统就可以自动登录
  • 用户主动退出(重装等情况视为主动退出)之后,使用用户名和密码登录

貌似没有看出什么区别,唯一的不同就是第二点:怎么不用密码登录,web使用的是cookie(由浏览器自动维护的),APP怎么登陆呢?由于APP本地不保存密码,那么也参考web,使用类似cookie的东西,我们叫他token吧,那问题就解决了,APP本地保存token,为了安全性,定期更新token,那再来看看会话的保持。

会话(session)(保持状态)

如果用户登录了,怎么保持登录状态呢,web有cookie和session配合解决这个问题,下面先简单说一下我对这两个东西的理解,因为APP会话就是参考这个原理设计的。

cookie:是由浏览器维护的,每次请求浏览器都会把cookie放在header里面(如果有的话),也可以看做js的可以访问本地存储数据的位置之一(另一个就是local storage)

session:由于http是无状态的,但是有时候服务器需要把这次请求的数据保存下来留给下一次请求使用,即需要维护连续请求的状态,这个时候服务器就借助cookie,当浏览器发送请求来服务器的时候,服务器会生成一个唯一的值,写到cookie中返回给浏览器,同时生成一个session对象,这样session和cookie值就有了一一对应关系了,浏览下一次访问的时候就会带着这个cookie值,这个时候服务器就会获得cookie的值,然后在自己的缓存里面查找是否存在和该cookie关联的session

因为cookie和session的配合,shiro可以本身很好的支持web的登录和会话保持,对于APP来说也可以借鉴cookie和session的这种实现方式,唯一存在的问题,就是web的cookie是由浏览器维护的,自动将cookie放在header里面,那我们APP只要把服务器返回的cookie放在header里面,每次访问服务器的时候带上就可以了。

免密码登录

解决了登录和会话保持的问题,还剩一个免密码登陆:

web:因为一般网页主需要记住7天密码(或者稍微更长)的功能就可以了,可以使用cookie实现,而且shiro也提供了记住密码的功能,在服务器端session不需要保存过长时间

APP:因为APP免密码登录时间需要较长(在用户不主动退出的时候,应该一直保持登录状态),这样子在服务器端就得把session保存很长时间,给服务器内存和性能上造成较大的挑战,存在的矛盾是:APP需要较长时间的免密码登录,而服务器不能保存过长时间的session,解决办法:

  • APP第一次登录,使用用户名和密码,如果登录成功,将cookie保存在APP本地(比如sharepreference),后台将cookie值保存到user表里面
  • APP访问服务器,APP将cookie添加在heade里面,服务器session依然存在,可以正常访问
  • APP访问服务器,APP将cookie添加在heade里面,服务器session过期,访问失败,由APP自动带着保存在本地的cookie去服务器登录,服务器可以根据cookie和用户名进行登录,这样服务器又有session,会生成新的cookie返回给APP,APP更新本地cookie,又可以正常访问
  • 用户手动退出APP,删除APP本次存储的cookie,下次登录使用用户名和密码登录

这种方法存在的问题:

  1. cookie保存在APP本地,安全性较低,可以通过加密cookie增加安全性
  2. 每次服务器session失效之后,得由APP再次发起登录请求(虽然用户是不知道的),但是这样本身就会增加访问次数,好在请求数量并不是很大,不过这种方式会使cookie经常更新,反而增加了安全性

这里给出另外一种实现方式:

实现自己的SessionDao,将session保存在数据库,这样子的好处是,session不会大量堆积在内存中,就不需要考虑session的过期时间了,对于APP这种需要长期保存session的情况来说,就可以无限期的保存session了,也就不用APP在每次session过期之后重新发送登录请求了。实现方式如下:

为了使用Hibernate将Session保存到数据库,新建一个SimpleSessionEntity

package org.lack.entity;

import java.io.Serializable;

import org.apache.shiro.session.mgt.SimpleSession;

import com.phy.em.user.entity.User;

public class SimpleSessionEntity {

    private Long id;
    private String cookie;
    private Serializable session;

    public Long getId() {
        return id;
    }
    public void setId(Long id) {
        this.id = id;
    }
    public Serializable entity() {
        return session;
    }
    public void setSession(Serializable session) {
        this.session = session;
    }
    public String getCookie() {
        return cookie;
    }
    public void setCookie(String cookie) {
        this.cookie = cookie;
    }
    public Serializable getSession() {
        return session;
    }
}
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

<hibernate-mapping package="org.lack.entity">
    <class name="SimpleSessionEntity" table="session">
        <!-- 标识 -->
        <id name="id">
            <column name="id"></column>
            <generator class="increment"></generator>
        </id>

        <property name="session">
            <column name="session"></column>
        </property>

        <property name="cookie">
            <column name="cookie"></column>
        </property>

    </class>
</hibernate-mapping>

以上贴出来的是SimpleSessionEntity的映射文件,特别要注意的是Hibernate也是支持把对象保存在数据库中的,但是该实体要实现Serializable,在取出来的时候强转为对应的对象即可,所以这里session的类型为Serializable

新建session缓存的方式的类,这里继承自EnterpriseCacheSessionDAO,可以使用ehcache作为二级缓存,一定要记得实现save、update、readSession、delete方法,特别是save方法只是保存一个基本的session,重要的attribute都是update的,在readSession中从数据库中读取即可

package org.lack.dao

import java.io.Serializable;
import java.util.Date;
import org.apache.log4j.Logger;
import org.apache.shiro.session.Session;
import org.apache.shiro.session.UnknownSessionException;
import org.apache.shiro.session.mgt.SimpleSession;
import org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO;
import org.springframework.transaction.annotation.Transactional;
import com.phy.em.common.dao.IBaseDao;
import com.phy.em.common.shiro.entity.SimpleSessionEntity;
import com.phy.em.user.entity.User;
public class SessionEntityDao extends EnterpriseCacheSessionDAO {

    private IBaseDao<User> baseDao;
    private IBaseDao<SimpleSessionEntity> sessionDao;
    private Logger log = Logger.getLogger(SessionEntityDao.class);

    @Override
    public Serializable create(Session session) {
        // 先保存到缓存中
        Serializable cookie = super.create(session);
        // 新建一个SimpleSessionEntity,然后保存到数据库
        SimpleSessionEntity entity = new SimpleSessionEntity();
        entity.setSession((SimpleSession)session);
        entity.setCookie(cookie.toString());
        sessionDao.save(entity);

        return cookie;
    }

    @Override
    public void update(Session session) throws UnknownSessionException {
        super.update(session);
        SimpleSessionEntity entity = getEntity(session.getId());
        if(entity != null){
            entity.setSession((SimpleSession)session);
            sessionDao.update(entity);
        }
    }

    @Override
    public Session readSession(Serializable sessionId) throws UnknownSessionException {
        Session session = null;

        try{
            session = super.readSession(sessionId);
        } catch(Exception e){

        }

        // 如果session已经被删除,则从数据库中查询session
        if(session == null){
            SimpleSessionEntity entity = getEntity(session.getId());
            if(entity != null){
                session = (Session) entity.getSession();
            }

        } else{
            // 如果session没有被删除,则判断session是否过期
            if(isExpire(session)){
                // session过期
                User user = getUser(sessionId);
                if(user != null){
                    // 如果该用户是APP用户(user不为空说明就是),则判断session是否过期,如果过期则修改最后访问时间
                    ((SimpleSession)session).setLastAccessTime(new Date());
                }
            }
        }
        return session;
    }

    @Override
    public void delete(Session session) {
        super.delete(session);
    }

    private User getUser(Serializable sessionId){
        String hql = "from User user where user.cookie =‘" + sessionId + "‘";
        return baseDao.findUniqueByHQL(hql);
    }

    private SimpleSessionEntity getEntity(Serializable sessionId){
        String hql = "from SimpleSessionEntity entity where entity.cookie =‘" + sessionId + "‘";
        return sessionDao.findUniqueByHQL(hql);
    }

    private boolean isExpire(Session session){
        long timeout = session.getTimeout();
        long lastTime = session.getLastAccessTime().getTime();
        long current = new Date().getTime();
        if((lastTime + timeout) > current){
            return false;
        }
        return true;
    }

    public void setBaseDao(IBaseDao<User> baseDao) {
        this.baseDao = baseDao;
    }

    public void setSessionDao(IBaseDao<SimpleSessionEntity> sessionDao) {
        this.sessionDao = sessionDao;
    }

}

我卡UI被自己蠢哭了,在继承EnterpriseCacheSessionDAO 只实现了readSession,妄想自己新建一个SimpleSession来返回给shiro使用,尝试过很多次之后不行,跟着调试了很多shiro远吗,发现在SimpleSession中Shiro不仅设置了基本的属性,更重要的是设置了Attribute,但是我自己新建的SimpleSession没有,所以认证是失败的,所以在此敬告各位一定要记得实现save和update方法。

虽然走了很多弯路,但是随着对shiro源码的调试学习,对shiro了解更深了,不再仅仅停留在只会使用的地步上,有深入。



好了到此为止,正文完了,我们开头提出的问题都解决完了,记下来掰扯掰扯在做APP登录过程中遇到的问题以及一些自己的体会。

关于系统安全

在考虑APP登录的时候考虑了很多安全因素

  • 在用户使用用户名和密码登录的时候,对密码进行加密
  • 会话保持如果使用cookie这种技术的话,存在被别人截取cookie之后就可以认证登录了
  • 在本地保存密码肯定是不合适的,如果保存cookie(token)的话,手机被root之后,很容易就可以看得到了,比如Android的就只是一个xml文件,所以cookie保存要加密,加密之后提高了破解门槛,加密就涉及到秘钥的问题了,秘钥如果写在代码里面,java被反编译之后就很容易秘钥找得到了,当然了google早就已经开始支持NDK(即Android原生开发,这个原生是指使用C/C++开发,编译成为so文件,在java中调用),这样又加大了破解难度,使用Hybrid就更不用说了,直接解压安装包就可以看到了。
  • cookie如果保存在本地,更新的时机(频率)是什么,这样就算是cookie泄露了,也只是在某一段时间内有用(当然了,对于“有心人”来说“这段时间”已经足够做一些事儿了)

在考虑这些问题的时候我意识到:

  • 安全只是相对的(攻与防本来就是一件你强我更强的事,有攻击,防御就会增强,防御增强了,攻击要想成功就得更强)
  • 安全不是在技术上越安全越好,要考虑实际应用场合、投入的成本(往往不是技术不能实现,而是要考虑实际情况,包括成本、信息的重要程度等等,这就是一种工程思维)
时间: 2024-07-31 22:23:26

shiro实现APP、web统一登录认证和权限管理的相关文章

Spring boot 入门(四):集成 Shiro 实现登陆认证和权限管理

本文是接着上篇博客写的:Spring boot 入门(三):SpringBoot 集成结合 AdminLTE(Freemarker),利用 generate 自动生成代码,利用 DataTable 和 PageHelper 进行分页显示.按照前面的博客,已经可以搭建一个简单的 Spring Boot 系统,本篇博客继续对此系统进行改造,主要集成了 Shiro 权限认证框架,关于 Shiro 部分,在本人之前的博客(认证与Shiro安全框架)有介绍到,这里就不做累赘的介绍. 此系列的博客为实践部分

SpringBoot(十四):springboot整合shiro-登录认证和权限管理

原文出处: 纯洁的微笑 这篇文章我们来学习如何使用Spring Boot集成Apache Shiro.安全应该是互联网公司的一道生命线,几乎任何的公司都会涉及到这方面的需求.在Java领域一般有Spring Security.Apache Shiro等安全框架,但是由于Spring Security过于庞大和复杂,大多数公司会选择Apache Shiro来使用,这篇文章会先介绍一下Apache Shiro,在结合Spring Boot给出使用案例. Apache Shiro What is Ap

shiro实现app和web统一登录

(转自:http://www.cnblogs.com/sunshine-2015/p/5515429.html) 先说下背景,项目包含一个管理系统(web)和门户网站(web),还有一个手机APP(包括Android和IOS),三个系统共用一个后端,在后端使用shiro进行登录认证和权限控制.好的,那么问题来了web和APP都可以用shiro认证吗?两者有什么区别?如果可以,解决方案是什么?看着大家焦急的小眼神,接下来挨个解决上面的问题. web和APP可以用shiro统一登录认证吗? 可以.假

Shiro学习(23)多项目集中权限管理

在做一些企业内部项目时或一些互联网后台时:可能会涉及到集中权限管理,统一进行多项目的权限管理:另外也需要统一的会话管理,即实现单点身份认证和授权控制. 学习本章之前,请务必先学习<第十章 会话管理>和<第十六章 综合实例>,本章代码都是基于这两章的代码基础上完成的. 本章示例是同域名的场景下完成的,如果跨域请参考<第十五章 单点登录>和<第十七章 OAuth2集成>了解使用CAS或OAuth2实现跨域的身份验证和授权.另外比如客户端/服务器端的安全校验可参考

mongodb之用户/认证/角色/权限管理

前言 用户权限管理很重要,只给需要的权限,防止应用系统漏洞导致脱库 认证和授权 Authentication 认证识别,解决我是谁 Authorization 操作授权,我能做什么 认证机制 MONGODB-CR 官方自定义实现认证机制,通过用户名和密码,通过challenge-response方式,来识别和验证授权.SCRAM-SHA-1认证机制有更好的安全性,新版本默认使用SCRAM-SHA-1.不建议使用MONGODB-CR模式. SCRAM-SHA-1 3.0版本新加功能,Mongodb

shiro 实现登录认证和权限控制

1 添加依赖jar包 <dependency> <groupId>org.apache.shiro</groupId> <artifactId>shiro-core</artifactId> <version>1.3.2</version></dependency><dependency> <groupId>org.apache.shiro</groupId> <art

elk使用x-pack实现安全认证及权限管理功能

1.x-pack介绍: x-pack是一个基于elastic安全的插件包.可以实现安全认证,监控.报表.图形等功能.自elk5.0版本以后集成到elk中 2.特点: 安装方便,灵活.虽然已经集成,但是可以随意的启用或禁用某个功能 3.功能使用: 选项参数值为布尔值.true:启用,false禁用 功能名称:文件配置格式:适用组件 图形展示: xpack.graph.enabled:只使用于kibana组件 报表统计: pack.reporting.enabled:只使用于kibana组件 报警通

springboot(五):springboot整合shiro-登录认证和权限管理

http://www.ityouknow.com/springboot/2017/06/26/springboot-shiro.html 原文地址:https://www.cnblogs.com/cnki/p/9021985.html

Shiro 登录认证源码详解

Shiro 登录认证源码详解 Apache Shiro 是一个强大且灵活的 Java 开源安全框架,拥有登录认证.授权管理.企业级会话管理和加密等功能,相比 Spring Security 来说要更加的简单. 本文主要介绍 Shiro 的登录认证(Authentication)功能,主要从 Shiro 设计的角度去看这个登录认证的过程. 一.Shiro 总览 首先,我们思考整个认证过程的业务逻辑: 获取用户输入的用户名,密码: 从服务器数据源中获取相应的用户名和密码: 判断密码是否匹配,决定是否