Single authorization (SSO) using JASIG CAS. Part 2

Greetings, dear Habro readers. Here is a continuation of a series of articles about JASIG CAS. In this part I will tell you how to collect the CAS artifact and start working with it. Before reading further, I hope you read the first part .

We tuned, gathered ... sorted out.

As they say, the right attitude is half the battle. In order to properly configure and build your version of CAS, you should have a good idea of ​​how Spring and Maven work.
If you want to know the dao of CAS settings from beginning to end, then here you are . I’ll tell you about the basic things you need to know in order to successfully launch CAS in the environment that I described in the first article.
First, I’ll list the files that may be needed for configuration. After that, I will dwell in more detail on those of them that I consider the most important. The original list can be found here .

Configuration files

• WEB-INF / classes / log4j.xml. This file contains the logging settings. If you wish, you can add your own loggers, CAS does not impose any restrictions.
• WEB-INF / cas-servlet.xml. This is the Spring MVC configuration of servlets that process CAS service URLs.
• WEB-INF / cas.properties. It contains the URLs of service services, an SQL dialect, and generally any properties you can think of, you can add here.
• WEB-INF / deployerConfigContext.xml. Almost all service settings are in this file.
• WEB-INF / login-webflow.xml. Here, with the help of Spring Web Flow, the authorization flow is configured.
• WEB-INF / restlet-servlet.xml. Setting up RESTful APIs. In theory, you will never have to change this file.
• WEB-INF / classes / messages _ *. Properties. This is a set of property files used to localize CAS.
• WEB-INF / spring-configuration. This directory contains the settings for most components. Many of them can be easily redefined.

Configuration files located in WEB-INF / spring-configuration

• applicationContext.xml. Contains standard beans that normally do not need to be redefined, such as the Autowiring scheduler and Quartz task settings.
• ticketRegistry.xml. Ticket registry. You are unlikely to want to change it.
• argumentExtractorsConfiguration.xml. Responsible for the choice of protocol. By default, CAS and SAML.
• propertyFileConfigurer.xml. Specifies the path from where to get properties. By default from WEB-INF / cas.properties
• securityContext.xml.
• ticketExpirationPolicies.xml. Settings related to the creation and validation of tickets.
• ticketGrantingTicketCookieGenerator.xml. Describes how to create a TGT. Most likely it will not have to be changed.
  

deploymentconfigContext.xml

And so, the key CAS configuration file is deployerConfigContext.xml. This is a fairly large file, so I will parse it in pieces from top to bottom.
At the very beginning of the file is a list of credential resolvers. Resolvers are responsible for retrieving credentials from an authorization request arriving at the server.

...

If you will not use anything other than the login / password provided from the authorization form, then this section can be safely left as is.

The following is a description of the handlers that are responsible for how CAS will use the credentials received. I use them to search for a user in LDAP

IMPORTANT! In the product environment, be sure to remove SimpleTestUsernamePasswordAuthenticationHandler .

IMPORTANT! Note the p parameter : timeout = "$ {ldapReadConnectTimeout}" . This is a read / connect timeout with LDAP. Without setting this parameter, the standard values ​​will not be overwritten, not even looking at the set parameters com.sun.jndi.ldap.connect.timeout com.sun.jndi.ldap.read.timeout, which will be discussed later.

The next block of configurations is associated with the configuration of the user data source. I will give a configuration example when users are stored in openLdap.
There are two ways to search for users in LDAP:

• FastBindLdapAuthenticationHandler. It is the fastest, but only suitable in cases where a distinguished name (DN) can be directly constructed from the credentials, i.e. uid =% u, ou = users, dc = domain. Where% u is the login provided.
  
• BindLdapAuthenticationHandler. It is a bit slower, but allows more freedom in choosing the right record. It works in 2 stages - from the beginning there is an LDAP bind. Credentials for bind are taken from contextSource, which I will talk about a little later. Stage 2 - LDAP search using a filter.
  

IMPORTANT! When working with LDAP, base is used differently for search and bind operations. For bind, you must always specify the full name of the entry, i.e., for example, cn = user, dc = sso, dc = ru, where base is dc = sso, dc = ru. Therefore, the base in the contextSource setting should always be filled and userDN is always the full name of the user under whom CAS is authorized in LDAP.

During the search, searchBase is added to the search filter to limit the crawl area. It may well be empty, in this case the search criteria in the directory is determined only by the filter.

An example of setting contextSource.

ldap://your.host.nameORip

Parameters com.sun.jndi.ldap. (Connect, read) .timeout are responsible for timeouts when connecting and reading data from LDAP, respectively.

There shouldn’t be any problems with userDetailsService, so let's move on to the last important setting - the service repository. There are several ways to store registered services. The default is the inMemory repository. This option is not suitable for the product environment and for those cases when you want to share a single list of services among several CAS servers. We use MySql, deployed on the same machine as the CAS server. If this option is acceptable for you, you can simply copy this configuration and substitute your username / password.

org.hibernate.dialect.MySQLDialectupdate

ticketExpirationPolicies.xml

This is another important configuration file. It describes expiration policies for ST and TGT. You may need to increase the parameter values ​​for ST if you intend to change the interaction protocol, there are serious network delays or the servers participating in SSO are poorly synchronized in time.

cas.properties

There are not many standard properties here.
cas.securityContext.serviceProperties.service. Its value can be for example https: // localhost: 8443 / cas / services / j_acegi_cas_security_check. This is the URL of the servlet that performs ticket checks. Here it looks like this: $ {service} since we prefer to make this and many other settings into the properties of MAVEN profiles and substitute them during assembly. How this is done, I will tell a little later.
cas.securityContext.serviceProperties.adminRoles = ROLE_ADMIN. This property contains the user role names from Spring Security. Users with these roles have access to the CAS service interfaces. This setting is directly related to userDetailsService from deployerConfigContext.xml.
cas.securityContext.casProcessingFilterEntryPoint.loginUrl.Along this path is a servlet that accepts user credentials.
cas.securityContext.ticketValidator.casServerUrlPrefix. CAS URL.
host.name. As I understand it, this parameter is mainly used as a prefix in the names TGT and ST. So you can choose any name to your taste.
database.hibernate.dialect. This property defines the Hibernate SQL dialect. In deployerConfigContext.xml we selected MySQl for storing services, so its value should be set to org.hibernate.dialect.MySQLDialect.

CAS allows you to specify a different design for your web interfaces using CAS themes. How this is done, I will probably tell in another article. Details on the topics can be found here .

Assembly

Now that you’ve figured out the settings, you can try to assemble your own artifact. We will collect using Maven war overlay
First, we will describe the properties that we will need later

3.0.4.RELEASE3.0.3.RELEASE3.4.82.0.21.6UTF-8

Important! Be sure to specify the resource encoding that will be used when building the project. Otherwise, you may have problems with the Russian text.

Add dependencies to the project in accordance with the settings made in deployerConfigContext.xml

org.jasig.cascas-server-webapp${cas.version}warruntimec3p0c3p00.9.1.2org.hibernatehibernate-entitymanager3.6.0.Finalhibernate-coreorg.hibernatemysqlmysql-connector-java5.1.14org.jasig.cascas-server-support-ldap${cas.version}org.hibernatehibernate-corejaxb-implcom.sun.xml.bindspring-expressionorg.springframeworkspring-expressionorg.springframeworkspring-expressionorg.springframework

Building with overlay is suitable when you do not need resource profiles and filters, but you want to use the resources of another project as a base for your assembly.
For example, if you need to replace deployerConfigContext.xml and cas.properties in an artifact, you can do it like this ...

maven-war-plugincasorg.jasig.cascas-server-webappWEB-INF/deployerConfigContext.xmlWEB-INF/cas.properties

Although this method is pretty good, I still recommend using profiles . They give significantly more freedom in configuring the application. With their help, for example, it is very simple to organize the assembly of artifacts for the product and test environments.
Now the build tag will look like this

maven-war-plugincassrc/main/configWEB-INFtrue

Now add profiles

testtrue
https://localhost:8443/cas/services/j_acegi_cas_security_check
prod
https://auth.tcsbank.ru:8443/cas/services/j_acegi_cas_security_check

It’s wise to put all the properties that differ in different environments into the profile tag.


Now you can create the directory / src / main / config and copy there all the resources for which you want to filter using Maven. As a result, the structure of your project may look something like the picture on the right.
It remains only to assemble the project, for example, for the food environment ...

mvn -e clean compile package -P prod

The -e modifier instructs to show more detailed information about the build process, including the stacktrace of any error that occurs.

Important! Before assembling, make sure that for all locales where you intend to use CAS, all messages are present. To do this, make sure that the messages file for the required locales contains the same messages as the file for the en locale. If this is not the case, you need to copy the recource Bundle into your project in the directory / webapp / WEB-INF / classes / and manually add the list of messages. Otherwise, CAS will not be able to display any service interface in which the necessary messages are missing.

Take off

Well, CAS is assembled and launched, and the last step separates us from the full-fledged single authorization service - adding trusted services. Detailed instructions on how to do this can be found here .

Important! The first service, CAS must be added. If this is not done, after adding any other service, the service interfaces will become unavailable and you most likely will have to manually clear the service store or add CAS to it.

In order to add a service to CAS, you need to go to the services management page at https: // $ {serverUrl} /services/add.html. Only an authorized user can access this page. User roles are configured in cas.properties and deployerConfigContext.xml.
Service URLs support ANT style templating. For example, to add all services located on the local machine to trusted ones, you can use this pattern - ht tp *: // localhost: * / **.

That's all for once. In the 3rd part I will tell you how to deal with some common problems, optimize performance and log in from external forms and even asynchronously.

Thank you for reading to the end)