Shiro & CAS Implementation single sign-on __shiro

Overview

Single sign-on is mainly used for multiple system integration, that is, in multiple systems, users need to log on to one central server at a time to access any one of these systems without having to log on multiple times.

This article uses the Open source framework Jasig CAS to complete a single sign-on. Download Address: Https://www.apereo.org/cas/download

Deploying Servers

This article server uses TOMCAT7, downloads the cas-server-4.0.0-release.zip, extracts it, Locate the Cas-server-webapp-4.0.0.war below the modules directory and copy directly to the WebApps folder. Start Tomcat, Access http://localhost:8080/cas-server-webapp-4.0.0, log on with Casuser/mellon, and log on successfully.

Tomcat does not open the HTTPS protocol by default, so this is accessed directly from the HTTP protocol. In order for the client to be successful at single sign-on under the HTTP protocol, you need to modify the configuration:

Web-inf\spring-configuration\ticketgrantingticketcookiegenerator.xml change p:cookiesecure= "true" to p:cookieSecure= " False

Web-inf\spring-configuration\warncookiegenerator.xml: Change p:cookiesecure= "true" to P:cookiesecure= "false"

Web-inf\deployerconfigcontext.xml: <bean class= " Org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler "P:httpclient-ref = "HttpClient"/> Add p:requiresecure= "false"

At this point, a simple single sign-on server is basically ready to deploy. Deploying Clients

The client needs to add dependencies on both the Shiro-cas and Cas-client-core packages. This is mainly about CAS-related configurations.

Configure Web.xml after

The <!--is used for single point exit, which is used to implement single point logout and optional configuration. -->

< listener >

< Listener-class > Org.jasig.cas.client.session.SingleSignOutHttpSessionListener </listener-class >

</Listener >

<!--the filter is used for single point logout and optional configuration. -->

< filter >

< Filter-name > CAS single Sign out filter </filter-name >

< Filter-class > Org.jasig.cas.client.session.SingleSignOutFilter </filter-class >

</Filter >

< filter-mapping >

< Filter-name > CAS single Sign out filter </filter-name >

< Url-pattern >/* </url-pattern >

</filter-mapping >

Custom Realm:

public class Mycasrealm extends Casrealm {

Private UserService UserService;

public void Setuserservice (UserService userservice) {

this. UserService = UserService;

}

@Override

Protected Authorizationinfo Dogetauthorizationinfo (principalcollection principals) {

String username = (string) principals.getprimaryprincipal ();

Simpleauthorizationinfo authorizationinfo = new Simpleauthorizationinfo ();

Authorizationinfo.setroles (Userservice.findroles (username));

Authorizationinfo.setstringpermissions (userservice.findpermissions (username));

return authorizationinfo;

}

}

Configuration

< Bean id = "Casrealm" class = "Package.for.your.MyCasRealm" >

< property name = "UserService" ref = "UserService"/>

< property name = "Cachingenabled" value = "true"/>

< property name = "Authenticationcachingenabled" value = "true"/>

< property name = "Authenticationcachename" value = "Authenticationcache"/>

< property name = "Authorizationcachingenabled" value = "true"/>

< property name = "Authorizationcachename" value = "Authorizationcache"/>

<!--This address is CAS server address-->

< property name = "Casserverurlprefix" value = "${shiro.casserver.url}"/>

<!--must be consistent with the service parameters in Loginurl, otherwise the server will judge the service mismatch-->

< property name = "Casservice" value = "${shiro.client.cas}"/>

</Bean >

Configuring CAS Filters

<bean id= "Casfilter" class= "Org.apache.shiro.cas.CasFilter" >

<property name= "Failureurl" value= "/casfailure.jsp"/>

</bean>

<bean id= "Shirofilter" class= "Org.apache.shiro.spring.web.ShiroFilterFactoryBean" >

<property name= "SecurityManager" ref = "SecurityManager"/>

<property name= "loginurl" value= "${shiro.login.url}"/>

<property name= "Successurl" value= "${shiro.login.success.url}"/>

<property name= "Filters" >

<util:map>

<entry key= "cas" value-ref = "Casfilter"/>

<entry key= "logout" value-ref = "Logoutfilter"/>

</util:map>

</property>

<property name= "Filterchaindefinitions" >

<value>

/casfailure.jsp = Anon

/cas = CAs

/logout = Logout

/** = user

</value>

</property>

</bean>

Above login URL My configuration is Http://localhost:8080/cas-server/login?service=http://localhost:8080/cas-client/cas, The service parameter is the address after which the services will jump.

/cas=cas: That is,/cas address is a server-side callback address, using Casfilter to get Ticket to log in.

Then through eclipse deployment, access to Http://localhost:8080/cas-client can be tested. In order to see the effect of single sign-on, you can directly copy a copy of the WebApps in the client as CLIENT2, only need to modify the address in the above configuration. If the user has logged in, then access Http://localhost:8080/cas-client2 found no longer jump to the login page, the user is already logged in state.

Another issue to note is that CAS server defaults to a single point of logout but there is no such effect, APP1, but APP2 can still access, if you look at the browser cookie, you will find that there are two SessionID, one is Jsessionid, The container is native and the other is configured in Shiro:

<!--session cookie template-->

< Bean id = "Sessionidcookie" class = "Org.apache.shiro.web.servlet.SimpleCookie" >

Singlesignoutfilter Discovery is a logoutrequest request, the original Singlesignouthandler created in the original session has been destroyed, because from a log out, A's Shiro sessions will also be destroyed,

But B's Shiro session has not been destroyed, so visit B or can access, single point log out there are problems-->

< Constructor-arg value = "Jsessionid"/>

< property name = "HttpOnly" value = "true"/>

< property name = "MaxAge" value = "-1"/>

If we change the SID to Jsessionid, the answer is that if you change to Jsessionid, it will cause a redirect loop, because when you log on, Shiro discovers that the Jsessionid in the browser's request is not or has expired, A jsessionid is generated to the browser, and the link is redirected to the server for authentication, the CAS service URL is returned to the client server after successful authentication, and with a ticket parameter. Because there is a singlesignoutfilter, when it is discovered that this is a Tocken request, Singlesignouthandler will invoke Request.getsession () to obtain the native session. If there is no native session, the Jsessionid is also created and saved to the browser cookie, and after the client server authenticates ticket to the CAS server, the client server redirects to the previous page. At this time Shiro found Jsessionid is generated in the Singlesignouthandler, in their own maintenance session can not be found, and will regenerate new sessions, and then login, and then redirect to CAS server authentication, Then redirect to the CAs service URL for the client server, unlike this call Session.getsession (true) in Singlesignouthandler, which is not newly created, and then loops. If using a SID would cause a single point of log out, if there are a, b two client servers, log out from a, will jump to the CAS server log out, the CAS server will be all through its certified service call Destroy Session method, But B's Shiro session has not been destroyed, so visit B or can access, single point log out of the problem

This is because I set Shiro Session manager for the Defaultwebsessionmanager, this manager directly abandoned the container session manager, to maintain their sessions, so there will be the problem described above. If we do not set, then Shiro will use the default Session Manager Servletcontainersessionmanager:web environment, which uses the Servlet container's sessions directly. Such a single point of log out can be used normally.

In addition, if we have to use Defaultwebsessionmanager, we will rewrite a singlesignoutfilter, Singlesignouthandler and Sessionmappingstorage.

If you do not use the spring framework, you can refer to the following configuration Web.xml

<?xml version= "1.0" encoding= "UTF-8"?>

< Web-app xmlns:xsi = "Http://www.w3.org/2001/XMLSchema-instance"

xmlns = "Http://java.sun.com/xml/ns/javaee" Xmlns:web = "http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"

Xsi:schemalocation = "Http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"

id = "webapp_id" Version = "2.5" >

< display-name > Ypshop Authority Manage </display-name >

< Context-param >

< Param-name > Webapprootkey </param-name >

< Param-value > Authority.root </param-value >

</Context-param >

<!--Note: This client is configured in a way that does not require spring support-->

< listener >

< Listener-class > Org.jasig.cas.client.session.SingleSignOutHttpSessionListener </listener-class >

</Listener >

< filter >

< Filter-name > CAS single Sign out filter </filter-name >

< Filter-class > Org.jasig.cas.client.session.SingleSignOutFilter </filter-class >

</Filter >

< filter-mapping >

< Filter-name > CAS single Sign out filter </filter-name >

< Url-pattern >/* </url-pattern >

</filter-mapping >

< filter >

< Filter-name > CAS authentication filter </filter-name >

< Filter-class > Org.jasig.cas.client.authentication.AuthenticationFilter </filter-class >

< Init-param >

< Param-name > Casserverloginurl </param-name >

< Param-value > Https://localhost:8443/cas-server/login </param-value >

</Init-param >

< Init-param >

< Param-name > ServerName </param-name >

< Param-value > https://localhost:8443 </param-value >

</Init-param >

</Filter >

< filter-mapping >

< Filter-name > CAS Aut