[CAS 5.0.1] Unable to browse any link of my CAS Client web application after successful user authentication through CAS Server

[John Barleycorn]

Good day everybody.

I am facing a problem on Apereo CAS 5.0.1, and after trying for an entire day to look for a solution by myself I decided to ask some help from the community. 

Oh, I am completely new to CAS, having started experimenting with this technology no more than 7 days ago, so I hope to be able to describe the problem scenario using the correct terminology...

I am currently trying to setup a lab-environment to provide SSO for a Spring Boot web application (as CAS Client), authenticating through CAS3 protocol on the Apereo CAS v.5.0.1

I have correctly configured the CAS Server to use an Apache Directory Server (v. 2.0.4) as authentication back-end for users.

After some research on internet and several attempts I was able to configure my security configuration class interfacing to the CAS (you can see down here a small excerpt):

@Configuration

@EnableWebSecurity

public class SecurityAccessConfiguration extends WebSecurityConfigurerAdapter {

private static final String[] PUBLIC_URLS = { 

"/", 

"/css/**", 

"/fonts/**", 

"/js/**", 

"/images/**" };

private static final String[] ADMIN_ONLY_URLS = {};

private static final String[] AUTHENTICATED_ONLY_URLS = {};

@Bean

public ServiceProperties serviceProperties() {

ServiceProperties serviceProperties = new ServiceProperties();

serviceProperties.setService("https://localhost:9998/");

serviceProperties.setSendRenew(false);

return serviceProperties;

}

@Bean

public CasAuthenticationProvider casAuthenticationProvider() {

CasAuthenticationProvider casAuthenticationProvider = new CasAuthenticationProvider();

casAuthenticationProvider.setAuthenticationUserDetailsService(authenticationUserDetailsService());

casAuthenticationProvider.setServiceProperties(serviceProperties());

casAuthenticationProvider.setTicketValidator(cas30ServiceTicketValidator());

casAuthenticationProvider.setKey("tako_client");

return casAuthenticationProvider;

}

@Bean

public AuthenticationUserDetailsService authenticationUserDetailsService() {

return new UserDetailsServiceImpl();

}

@Bean

public Cas30ServiceTicketValidator cas30ServiceTicketValidator() {

return new Cas30ServiceTicketValidator("https://localhost:8443/cas/p3/serviceValidate");

}

@Bean

public CasAuthenticationFilter casAuthenticationFilter() throws Exception {

CasAuthenticationFilter casAuthenticationFilter = new CasAuthenticationFilter();

casAuthenticationFilter.setAuthenticationManager(authenticationManager());

return casAuthenticationFilter;

}

@Bean

public CasAuthenticationEntryPoint casAuthenticationEntryPoint() {

CasAuthenticationEntryPoint casAuthenticationEntryPoint = new CasAuthenticationEntryPoint();

casAuthenticationEntryPoint.setLoginUrl("https://localhost:8443/cas/login");

casAuthenticationEntryPoint.setServiceProperties(serviceProperties());

return casAuthenticationEntryPoint;

}

@Override

protected void configure(HttpSecurity http) throws Exception {

http.addFilter(casAuthenticationFilter()).exceptionHandling().authenticationEntryPoint(casAuthenticationEntryPoint())

.and().csrf().disable().cors().disable()

.authorizeRequests().antMatchers(PUBLIC_URLS).anonymous()

.and()

.authorizeRequests().anyRequest().authenticated();

}

@Override

protected void configure(AuthenticationManagerBuilder auth) throws Exception {

auth.authenticationProvider(casAuthenticationProvider());

}

}

Now, everything seems to be working fine: I visit the homepage of my app, and when I click any other link on the page I am redirected to the login page of the CAS; 

from there I login with the username and password of the user stored on the Apache Directory Server and I am redirected on my web application homepage. Below you can see that the CAS is passing me back the TGT as part of the URL:

...But that's it unfortunately. Every time I try to click on any other link on the home page, I am just redirected to the homepage again, and the homepage URL shows each time a different ticket number each time I try to click a new link.

I attach another screenshot down here another screenshot with the network calls trace from Chrome developer tools:

Can anybody explain me where I am getting it wrong? Is it some wrong parameter in my Spring Boot configuration? Or maybe I should modify something in the configuration of the CAS server itself?

I thank you in advance for your support.

J.B.

[Dmitriy Kopylenko]

Hi there. For a simpler CASification of Spring Boot apps via CAS Java client (without much configuration ceremony), you might want to try this -> https://github.com/Unicon/cas-client-autoconfig-support

And here’s a sample Boot app demonstrating the use of this library -> https://github.com/cas-projects/bootiful-cas-client

Cheers,

D.

--
- CAS gitter chatroom: https://gitter.im/apereo/cas
- CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
- CAS documentation website: https://apereo.github.io/cas
- CAS project website: https://github.com/apereo/cas
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/6c2caada-42bd-43b0-83c2-89db59862f7b%40apereo.org.

[John Barleycorn]

Hi Dmitry, and thanks for your suggestion!

Actually, I was able to shorten the configuration of my web service a lot by using the cas-client-autoconfig-support library (less visual noise is always good to have), but when it comes to the problem I was having before, well, nothing has changed unfortunately.

One strange thing I noticed by comparing the workflow between my web application and the CAS server and the workflow described in details in the CAS protocol specification, is that after the user is authenticated by CAS and the client's browser get back the URL with the TGT,  my web application is not trying to contact the https://localhost:8443/cas/p3/serviceValidate endpoint to validate the Service Ticket, but rather the https://localhost:8443/cas/login endpoint again... Is it supposed to be so? 

Another idea I was thinking about, is it possible that I have to use a different strategy than the UserDetailsService interface to extract the authenticated user information, because somehow the TGT does not contains the right parameters necessary to get back from the CAS the XML assertion with the data of the authenticated user and other optional data? In this case, is there any configuration change I could make to my web app, or the CAS application.properties file or even the Service properties JSON file currently authorizing my app to the CAS?

Thank you in advance for any help!

J.B. 

On Tuesday, June 20, 2017 at 8:59:17 PM UTC+9, Dmitriy Kopylenko wrote:

Hi there. For a simpler CASification of Spring Boot apps via CAS Java client (without much configuration ceremony), you might want to try this -> https://github.com/Unicon/cas-client-autoconfig-support

And here’s a sample Boot app demonstrating the use of this library -> https://github.com/cas-projects/bootiful-cas-client

Cheers,

D.

[Ray Bon]

John,

Check config of your client. The order that client uses to process the request is important. For instance (java client uses filters), the first filter would check for logout request, after that check for validation request. The last filter would redirect to login. (There may be other filters between logout and login.)

If the client keeps redirecting to login, it could be that it is configured with the login redirect occurring before the validation check.

Ray

-- 
Ray Bon
Programmer analyst
Development Services, University Systems
2507218831 | CLE 023 | rb...@uvic.ca

[John Barleycorn]

Good afternoon Ray, and thanks for your message.

Well, looks like I am really running out of bullets now.

As per your suggestion I have defined a LogoutFilter to be applied before the CasAuthenticationFilter in the ACL of the configure(HTTPSecurity http) method of my security configuration class. Just to be clear, this is the LogoutFilter:

        @Bean

public LogoutFilter singleLogoutFilter() {

LogoutFilter logoutFilter = new LogoutFilter("https://localhost:8443/cas/logout?service=https://localhost:9998",

new SecurityContextLogoutHandler());

logoutFilter.setFilterProcessesUrl("/logout");

return logoutFilter;

}

And this is how I use it:

        @Override

protected void configure(HttpSecurity http) throws Exception {

http.addFilterBefore(singleLogoutFilter(), CasAuthenticationFilter.class)

.addFilter(casAuthenticationFilter()).exceptionHandling().authenticationEntryPoint(casAuthenticationEntryPoint())

.and()

.logout().logoutUrl("/logout").invalidateHttpSession(true).deleteCookies("JSESSIONID").permitAll()

.and()

.authorizeRequests().antMatchers(PUBLIC_URLS).permitAll()

.and()

                                .authorizeRequests().anyRequest().authenticated()

.and()

                                .csrf().disable().cors().disable(); 

              }

Nothing is changing :( 

I can clearly see from the CAS log that a service ticket is being created for my session:

2017-06-22 18:00:12,105 INFO [org.apereo.cas.services.DefaultServicesManagerImpl] - <Loaded 2 services from InMemoryServiceRegistryDaoImpl.>

2017-06-22 18:00:18,297 INFO [org.apereo.cas.CentralAuthenticationServiceImpl] - <Granted ticket [ST-7-soDBHgcsBNqnCgzJw5U7-TKY-IDaaS-Client07] for service [https://localhost:9998] and principal [operator]>

2017-06-22 18:00:18,299 INFO [org.apereo.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN

=============================================================

WHO: operator

WHAT: ST-7-soDBHgcsBNqnCgzJw5U7-TKY-IDaaS-Client07 for https://localhost:9998

ACTION: SERVICE_TICKET_CREATED

APPLICATION: CAS

WHEN: Thu Jun 22 18:00:18 JST 2017

CLIENT IP ADDRESS: 127.0.0.1

SERVER IP ADDRESS: 127.0.0.1

=============================================================

But this is all. 

I will rebuild in the next few hours my tiny demo web application using Spring MVC and Spring Security with classic XML configuration instead of Spring Boot, because I would like to understand if the problem is something in the way those technologies interact together with CAS, or if I am really just getting some part of the configuration wrong.

Of course, if anybody in this community already has a working Spring Boot configuration showing zero problems with CAS and would be so kind to share it with the rest of us, I would be the happiest person in the world.

Thanks! :D

J.B.

[Ray Bon]

John,

I have not used Spring Boot but you should not have to write your own filter unless you want some special processing. See here, https://apereo.github.io/cas/5.0.x/integration/CAS-Clients.html, for a launch to various clients and their config. For the java client there is also an example app that has an XML config, https://github.com/cas-projects/cas-sample-java-webapp.

Ray

[John Barleycorn]

Hi Ray, and thanks again for the support.

Well, it turned out that I was missing a very important piece of information (although, as everything regarding Apereo CAS documentation sometimes you REALLY have to dig the hell out of internet to find the right thing to do :D)

In regards of interfacing a Spring application to CAS, the official Spring Security reference (http://docs.spring.io/spring-security/site/docs/4.2.3.RELEASE/reference/htmlsingle/#cas-sequence) mentions that:

"Upon successful login, CAS will redirect the user’s browser back to the original service. It will also include a ticket parameter, which is an opaque string representing the "service ticket". [...] "Back in the service web application, the CasAuthenticationFilter is always listening for requests to /login/cas (this is configurable, but we’ll use the defaults in this introduction). The processing filter will construct a UsernamePasswordAuthenticationToken representing the service ticket. The principal will be equal to CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER, whilst the credentials will be the service ticket opaque value. This authentication request will then be handed to the configured AuthenticationManager.

My original ServiceProperties bean was configured with serviceProperties.setSettings("https://localhost:9998") instead of the correct version serviceProperties.setSettings("https://localhost:9998/login/cas").

This is why my service ticket was never going to be validated and I was constantly being redirected to the default homepage...

The problem is now solved, but thanks anyway for the community support!

And now...Onto the next challenge: Getting back from the LDAP authentication handler all the authenticated Principal attributes I need, so that I can pass them to the Model View of my pages! 

Cheers!

J.B.