You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
466 lines
26 KiB
466 lines
26 KiB
[[servlet-cas]] |
|
= CAS Authentication |
|
|
|
[[cas-overview]] |
|
== Overview |
|
JA-SIG produces an enterprise-wide single sign on system known as CAS. |
|
Unlike other initiatives, JA-SIG's Central Authentication Service is open source, widely used, simple to understand, platform independent, and supports proxy capabilities. |
|
Spring Security fully supports CAS, and provides an easy migration path from single-application deployments of Spring Security through to multiple-application deployments secured by an enterprise-wide CAS server. |
|
|
|
You can learn more about CAS at https://www.apereo.org. |
|
You will also need to visit this site to download the CAS Server files. |
|
|
|
[[cas-how-it-works]] |
|
== How CAS Works |
|
Whilst the CAS web site contains documents that detail the architecture of CAS, we present the general overview again here within the context of Spring Security. |
|
Spring Security 3.x supports CAS 3. |
|
At the time of writing, the CAS server was at version 3.4. |
|
|
|
Somewhere in your enterprise you will need to setup a CAS server. |
|
The CAS server is simply a standard WAR file, so there isn't anything difficult about setting up your server. |
|
Inside the WAR file you will customise the login and other single sign on pages displayed to users. |
|
|
|
When deploying a CAS 3.4 server, you will also need to specify an `AuthenticationHandler` in the `deployerConfigContext.xml` included with CAS. |
|
The `AuthenticationHandler` has a simple method that returns a boolean as to whether a given set of Credentials is valid. |
|
Your `AuthenticationHandler` implementation will need to link into some type of backend authentication repository, such as an LDAP server or database. |
|
CAS itself includes numerous ``AuthenticationHandler``s out of the box to assist with this. |
|
When you download and deploy the server war file, it is set up to successfully authenticate users who enter a password matching their username, which is useful for testing. |
|
|
|
Apart from the CAS server itself, the other key players are of course the secure web applications deployed throughout your enterprise. |
|
These web applications are known as "services". |
|
There are three types of services. |
|
Those that authenticate service tickets, those that can obtain proxy tickets, and those that authenticate proxy tickets. |
|
Authenticating a proxy ticket differs because the list of proxies must be validated and often times a proxy ticket can be reused. |
|
|
|
|
|
[[cas-sequence]] |
|
=== Spring Security and CAS Interaction Sequence |
|
The basic interaction between a web browser, CAS server and a Spring Security-secured service is as follows: |
|
|
|
* The web user is browsing the service's public pages. |
|
CAS or Spring Security is not involved. |
|
* The user eventually requests a page that is either secure or one of the beans it uses is secure. |
|
Spring Security's `ExceptionTranslationFilter` will detect the `AccessDeniedException` or `AuthenticationException`. |
|
* Because the user's `Authentication` object (or lack thereof) caused an `AuthenticationException`, the `ExceptionTranslationFilter` will call the configured `AuthenticationEntryPoint`. |
|
If using CAS, this will be the `CasAuthenticationEntryPoint` class. |
|
* The `CasAuthenticationEntryPoint` will redirect the user's browser to the CAS server. |
|
It will also indicate a `service` parameter, which is the callback URL for the Spring Security service (your application). |
|
For example, the URL to which the browser is redirected might be https://my.company.com/cas/login?service=https%3A%2F%2Fserver3.company.com%2Fwebapp%2Flogin/cas. |
|
* After the user's browser redirects to CAS, they will be prompted for their username and password. |
|
If the user presents a session cookie which indicates they've previously logged on, they will not be prompted to login again (there is an exception to this procedure, which we'll cover later). |
|
CAS will use the `PasswordHandler` (or `AuthenticationHandler` if using CAS 3.0) discussed above to decide whether the username and password is valid. |
|
* 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". |
|
Continuing our earlier example, the URL the browser is redirected to might be https://server3.company.com/webapp/login/cas?ticket=ST-0-ER94xMJmn6pha35CQRoZ. |
|
* 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`. |
|
* The `AuthenticationManager` implementation will be the `ProviderManager`, which is in turn configured with the `CasAuthenticationProvider`. |
|
The `CasAuthenticationProvider` only responds to ``UsernamePasswordAuthenticationToken``s containing the CAS-specific principal (such as `CasAuthenticationFilter.CAS_STATEFUL_IDENTIFIER`) and ``CasAuthenticationToken``s (discussed later). |
|
* `CasAuthenticationProvider` will validate the service ticket using a `TicketValidator` implementation. |
|
This will typically be a `Cas20ServiceTicketValidator` which is one of the classes included in the CAS client library. |
|
In the event the application needs to validate proxy tickets, the `Cas20ProxyTicketValidator` is used. |
|
The `TicketValidator` makes an HTTPS request to the CAS server in order to validate the service ticket. |
|
It may also include a proxy callback URL, which is included in this example: https://my.company.com/cas/proxyValidate?service=https%3A%2F%2Fserver3.company.com%2Fwebapp%2Flogin/cas&ticket=ST-0-ER94xMJmn6pha35CQRoZ&pgtUrl=https://server3.company.com/webapp/login/cas/proxyreceptor. |
|
* Back on the CAS server, the validation request will be received. |
|
If the presented service ticket matches the service URL the ticket was issued to, CAS will provide an affirmative response in XML indicating the username. |
|
If any proxy was involved in the authentication (discussed below), the list of proxies is also included in the XML response. |
|
* [OPTIONAL] If the request to the CAS validation service included the proxy callback URL (in the `pgtUrl` parameter), CAS will include a `pgtIou` string in the XML response. |
|
This `pgtIou` represents a proxy-granting ticket IOU. |
|
The CAS server will then create its own HTTPS connection back to the `pgtUrl`. |
|
This is to mutually authenticate the CAS server and the claimed service URL. |
|
The HTTPS connection will be used to send a proxy granting ticket to the original web application. |
|
For example, https://server3.company.com/webapp/login/cas/proxyreceptor?pgtIou=PGTIOU-0-R0zlgrl4pdAQwBvJWO3vnNpevwqStbSGcq3vKB2SqSFFRnjPHt&pgtId=PGT-1-si9YkkHLrtACBo64rmsi3v2nf7cpCResXg5MpESZFArbaZiOKH. |
|
* The `Cas20TicketValidator` will parse the XML received from the CAS server. |
|
It will return to the `CasAuthenticationProvider` a `TicketResponse`, which includes the username (mandatory), proxy list (if any were involved), and proxy-granting ticket IOU (if the proxy callback was requested). |
|
* Next `CasAuthenticationProvider` will call a configured `CasProxyDecider`. |
|
The `CasProxyDecider` indicates whether the proxy list in the `TicketResponse` is acceptable to the service. |
|
Several implementations are provided with Spring Security: `RejectProxyTickets`, `AcceptAnyCasProxy` and `NamedCasProxyDecider`. |
|
These names are largely self-explanatory, except `NamedCasProxyDecider` which allows a `List` of trusted proxies to be provided. |
|
* `CasAuthenticationProvider` will next request a `AuthenticationUserDetailsService` to load the `GrantedAuthority` objects that apply to the user contained in the `Assertion`. |
|
* If there were no problems, `CasAuthenticationProvider` constructs a `CasAuthenticationToken` including the details contained in the `TicketResponse` and a set of ``GrantedAuthority``s that contains at least `FACTOR_BEARER`. |
|
* Control then returns to `CasAuthenticationFilter`, which places the created `CasAuthenticationToken` in the security context. |
|
* The user's browser is redirected to the original page that caused the `AuthenticationException` (or a custom destination depending on the configuration). |
|
|
|
It's good that you're still here! |
|
Let's now look at how this is configured |
|
|
|
[[cas-client]] |
|
== Configuration of CAS Client |
|
The web application side of CAS is made easy due to Spring Security. |
|
It is assumed you already know the basics of using Spring Security, so these are not covered again below. |
|
We'll assume a namespace based configuration is being used and add in the CAS beans as required. |
|
Each section builds upon the previous section. |
|
A full CAS sample application can be found in the Spring Security xref:samples.adoc#samples[Samples]. |
|
|
|
|
|
[[cas-st]] |
|
=== Service Ticket Authentication |
|
This section describes how to setup Spring Security to authenticate Service Tickets. |
|
Often times this is all a web application requires. |
|
You will need to add a `ServiceProperties` bean to your application context. |
|
This represents your CAS service: |
|
|
|
[source,xml] |
|
---- |
|
<bean id="serviceProperties" |
|
class="org.springframework.security.cas.ServiceProperties"> |
|
<property name="service" |
|
value="https://localhost:8443/cas-sample/login/cas"/> |
|
<property name="sendRenew" value="false"/> |
|
</bean> |
|
---- |
|
|
|
The `service` must equal a URL that will be monitored by the `CasAuthenticationFilter`. |
|
The `sendRenew` defaults to false, but should be set to true if your application is particularly sensitive. |
|
What this parameter does is tell the CAS login service that a single sign on login is unacceptable. |
|
Instead, the user will need to re-enter their username and password in order to gain access to the service. |
|
|
|
The following beans should be configured to commence the CAS authentication process (assuming you're using a namespace configuration): |
|
|
|
[source,xml] |
|
---- |
|
<security:http entry-point-ref="casEntryPoint"> |
|
... |
|
<security:custom-filter position="CAS_FILTER" ref="casFilter" /> |
|
</security:http> |
|
|
|
<bean id="casFilter" |
|
class="org.springframework.security.cas.web.CasAuthenticationFilter"> |
|
<property name="authenticationManager" ref="authenticationManager"/> |
|
</bean> |
|
|
|
<bean id="casEntryPoint" |
|
class="org.springframework.security.cas.web.CasAuthenticationEntryPoint"> |
|
<property name="loginUrl" value="https://localhost:9443/cas/login"/> |
|
<property name="serviceProperties" ref="serviceProperties"/> |
|
</bean> |
|
---- |
|
|
|
For CAS to operate, the `ExceptionTranslationFilter` must have its `authenticationEntryPoint` property set to the `CasAuthenticationEntryPoint` bean. |
|
This can easily be done using xref:servlet/appendix/namespace/http.adoc#nsa-http-entry-point-ref[entry-point-ref] as is done in the example above. |
|
The `CasAuthenticationEntryPoint` must refer to the `ServiceProperties` bean (discussed above), which provides the URL to the enterprise's CAS login server. |
|
This is where the user's browser will be redirected. |
|
|
|
The `CasAuthenticationFilter` has very similar properties to the `UsernamePasswordAuthenticationFilter` (used for form-based logins). |
|
You can use these properties to customize things like behavior for authentication success and failure. |
|
|
|
Next you need to add a `CasAuthenticationProvider` and its collaborators: |
|
|
|
[source,xml,attrs="-attributes"] |
|
---- |
|
<security:authentication-manager alias="authenticationManager"> |
|
<security:authentication-provider ref="casAuthenticationProvider" /> |
|
</security:authentication-manager> |
|
|
|
<bean id="casAuthenticationProvider" |
|
class="org.springframework.security.cas.authentication.CasAuthenticationProvider"> |
|
<property name="authenticationUserDetailsService"> |
|
<bean class="org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper"> |
|
<constructor-arg ref="userService" /> |
|
</bean> |
|
</property> |
|
<property name="serviceProperties" ref="serviceProperties" /> |
|
<property name="ticketValidator"> |
|
<bean class="org.apereo.cas.client.validation.Cas20ServiceTicketValidator"> |
|
<constructor-arg index="0" value="https://localhost:9443/cas" /> |
|
</bean> |
|
</property> |
|
<property name="key" value="an_id_for_this_auth_provider_only"/> |
|
</bean> |
|
|
|
<security:user-service id="userService"> |
|
<!-- Password is prefixed with {noop} to indicate to DelegatingPasswordEncoder that |
|
NoOpPasswordEncoder should be used. |
|
This is not safe for production, but makes reading |
|
in samples easier. |
|
Normally passwords should be hashed using BCrypt --> |
|
<security:user name="joe" password="{noop}joe" authorities="ROLE_USER" /> |
|
... |
|
</security:user-service> |
|
---- |
|
|
|
The `CasAuthenticationProvider` uses a `UserDetailsService` instance to load the authorities for a user, once they have been authenticated by CAS. |
|
We've shown a simple in-memory setup here. |
|
Note that the `CasAuthenticationProvider` does not actually use the password for authentication, but it does use the authorities. |
|
|
|
The beans are all reasonably self-explanatory if you refer back to the <<cas-how-it-works,How CAS Works>> section. |
|
|
|
This completes the most basic configuration for CAS. |
|
If you haven't made any mistakes, your web application should happily work within the framework of CAS single sign on. |
|
No other parts of Spring Security need to be concerned about the fact CAS handled authentication. |
|
In the following sections we will discuss some (optional) more advanced configurations. |
|
|
|
|
|
[[cas-singlelogout]] |
|
=== Single Logout |
|
The CAS protocol supports Single Logout and can be easily added to your Spring Security configuration. |
|
Below are updates to the Spring Security configuration that handle Single Logout |
|
|
|
[source,xml] |
|
---- |
|
<security:http entry-point-ref="casEntryPoint"> |
|
... |
|
<security:logout logout-success-url="/cas-logout.jsp"/> |
|
<security:custom-filter ref="requestSingleLogoutFilter" before="LOGOUT_FILTER"/> |
|
<security:custom-filter ref="singleLogoutFilter" before="CAS_FILTER"/> |
|
</security:http> |
|
|
|
<!-- This filter handles a Single Logout Request from the CAS Server --> |
|
<bean id="singleLogoutFilter" class="org.apereo.cas.client.session.SingleSignOutFilter"/> |
|
|
|
<!-- This filter redirects to the CAS Server to signal Single Logout should be performed --> |
|
<bean id="requestSingleLogoutFilter" |
|
class="org.springframework.security.web.authentication.logout.LogoutFilter"> |
|
<constructor-arg value="https://localhost:9443/cas/logout"/> |
|
<constructor-arg> |
|
<bean class= |
|
"org.springframework.security.web.authentication.logout.SecurityContextLogoutHandler"/> |
|
</constructor-arg> |
|
<property name="filterProcessesUrl" value="/logout/cas"/> |
|
</bean> |
|
---- |
|
|
|
The `logout` element logs the user out of the local application, but does not end the session with the CAS server or any other applications that have been logged into. |
|
The `requestSingleLogoutFilter` filter will allow the URL of `/spring_security_cas_logout` to be requested to redirect the application to the configured CAS Server logout URL. |
|
Then the CAS Server will send a Single Logout request to all the services that were signed into. |
|
The `singleLogoutFilter` handles the Single Logout request by looking up the `HttpSession` in a static `Map` and then invalidating it. |
|
|
|
It might be confusing why both the `logout` element and the `singleLogoutFilter` are needed. |
|
It is considered best practice to logout locally first since the `SingleSignOutFilter` just stores the `HttpSession` in a static `Map` in order to call invalidate on it. |
|
With the configuration above, the flow of logout would be: |
|
|
|
* The user requests `/logout` which would log the user out of the local application and send the user to the logout success page. |
|
* The logout success page, `/cas-logout.jsp`, should instruct the user to click a link pointing to `/logout/cas` in order to logout out of all applications. |
|
* When the user clicks the link, the user is redirected to the CAS single logout URL (https://localhost:9443/cas/logout). |
|
* On the CAS Server side, the CAS single logout URL then submits single logout requests to all the CAS Services. |
|
On the CAS Service side, Apereo's `SingleSignOutFilter` processes the logout request by invalidating the original session. |
|
|
|
|
|
|
|
The next step is to add the following to your web.xml |
|
|
|
[source,xml] |
|
---- |
|
<filter> |
|
<filter-name>characterEncodingFilter</filter-name> |
|
<filter-class> |
|
org.springframework.web.filter.CharacterEncodingFilter |
|
</filter-class> |
|
<init-param> |
|
<param-name>encoding</param-name> |
|
<param-value>UTF-8</param-value> |
|
</init-param> |
|
</filter> |
|
<filter-mapping> |
|
<filter-name>characterEncodingFilter</filter-name> |
|
<url-pattern>/*</url-pattern> |
|
</filter-mapping> |
|
<listener> |
|
<listener-class> |
|
org.apereo.cas.client.session.SingleSignOutHttpSessionListener |
|
</listener-class> |
|
</listener> |
|
---- |
|
|
|
When using the SingleSignOutFilter you might encounter some encoding issues. |
|
Therefore it is recommended to add the `CharacterEncodingFilter` to ensure that the character encoding is correct when using the `SingleSignOutFilter`. |
|
Again, refer to Apereo CAS's documentation for details. |
|
The `SingleSignOutHttpSessionListener` ensures that when an `HttpSession` expires, the mapping used for single logout is removed. |
|
|
|
|
|
[[cas-pt-client]] |
|
=== Authenticating to a Stateless Service with CAS |
|
This section describes how to authenticate to a service using CAS. |
|
In other words, this section discusses how to setup a client that uses a service that authenticates with CAS. |
|
The next section describes how to setup a stateless service to Authenticate using CAS. |
|
|
|
|
|
[[cas-pt-client-config]] |
|
==== Configuring CAS to Obtain Proxy Granting Tickets |
|
In order to authenticate to a stateless service, the application needs to obtain a proxy granting ticket (PGT). |
|
This section describes how to configure Spring Security to obtain a PGT building upon thencas-st[Service Ticket Authentication] configuration. |
|
|
|
The first step is to include a `ProxyGrantingTicketStorage` in your Spring Security configuration. |
|
This is used to store PGT's that are obtained by the `CasAuthenticationFilter` so that they can be used to obtain proxy tickets. |
|
An example configuration is shown below |
|
|
|
[source,xml] |
|
---- |
|
<!-- |
|
NOTE: In a real application you should not use an in memory implementation. |
|
You will also want to ensure to clean up expired tickets by calling |
|
ProxyGrantingTicketStorage.cleanup() |
|
--> |
|
<bean id="pgtStorage" class="org.apereo.cas.client.proxy.ProxyGrantingTicketStorageImpl"/> |
|
---- |
|
|
|
The next step is to update the `CasAuthenticationProvider` to be able to obtain proxy tickets. |
|
To do this replace the `Cas20ServiceTicketValidator` with a `Cas20ProxyTicketValidator`. |
|
The `proxyCallbackUrl` should be set to a URL that the application will receive PGT's at. |
|
Last, the configuration should also reference the `ProxyGrantingTicketStorage` so it can use a PGT to obtain proxy tickets. |
|
You can find an example of the configuration changes that should be made below. |
|
|
|
[source,xml] |
|
---- |
|
<bean id="casAuthenticationProvider" |
|
class="org.springframework.security.cas.authentication.CasAuthenticationProvider"> |
|
... |
|
<property name="ticketValidator"> |
|
<bean class="org.apereo.cas.client.validation.Cas20ProxyTicketValidator"> |
|
<constructor-arg value="https://localhost:9443/cas"/> |
|
<property name="proxyCallbackUrl" |
|
value="https://localhost:8443/cas-sample/login/cas/proxyreceptor"/> |
|
<property name="proxyGrantingTicketStorage" ref="pgtStorage"/> |
|
</bean> |
|
</property> |
|
</bean> |
|
---- |
|
|
|
The last step is to update the `CasAuthenticationFilter` to accept PGT and to store them in the `ProxyGrantingTicketStorage`. |
|
It is important the `proxyReceptorUrl` matches the `proxyCallbackUrl` of the `Cas20ProxyTicketValidator`. |
|
An example configuration is shown below. |
|
|
|
[source,xml] |
|
---- |
|
|
|
<bean id="casFilter" |
|
class="org.springframework.security.cas.web.CasAuthenticationFilter"> |
|
... |
|
<property name="proxyGrantingTicketStorage" ref="pgtStorage"/> |
|
<property name="proxyReceptorUrl" value="/login/cas/proxyreceptor"/> |
|
</bean> |
|
|
|
---- |
|
|
|
[[cas-pt-client-sample]] |
|
==== Calling a Stateless Service Using a Proxy Ticket |
|
Now that Spring Security obtains PGTs, you can use them to create proxy tickets which can be used to authenticate to a stateless service. |
|
The CAS xref:samples.adoc#samples[sample application] contains a working example in the `ProxyTicketSampleServlet`. |
|
Example code can be found below: |
|
|
|
[tabs] |
|
====== |
|
Java:: |
|
+ |
|
[source,java,role="primary"] |
|
---- |
|
protected void doGet(HttpServletRequest request, HttpServletResponse response) |
|
throws ServletException, IOException { |
|
// NOTE: The CasAuthenticationToken can also be obtained using |
|
// SecurityContextHolder.getContext().getAuthentication() |
|
final CasAuthenticationToken token = (CasAuthenticationToken) request.getUserPrincipal(); |
|
// proxyTicket could be reused to make calls to the CAS service even if the |
|
// target url differs |
|
final String proxyTicket = token.getAssertion().getPrincipal().getProxyTicketFor(targetUrl); |
|
|
|
// Make a remote call using the proxy ticket |
|
final String serviceUrl = targetUrl+"?ticket="+URLEncoder.encode(proxyTicket, "UTF-8"); |
|
String proxyResponse = CommonUtils.getResponseFromServer(serviceUrl, "UTF-8"); |
|
... |
|
} |
|
---- |
|
|
|
Kotlin:: |
|
+ |
|
[source,kotlin,role="secondary"] |
|
---- |
|
protected fun doGet(request: HttpServletRequest, response: HttpServletResponse?) { |
|
// NOTE: The CasAuthenticationToken can also be obtained using |
|
// SecurityContextHolder.getContext().getAuthentication() |
|
val token = request.userPrincipal as CasAuthenticationToken |
|
// proxyTicket could be reused to make calls to the CAS service even if the |
|
// target url differs |
|
val proxyTicket = token.assertion.principal.getProxyTicketFor(targetUrl) |
|
|
|
// Make a remote call using the proxy ticket |
|
val serviceUrl: String = targetUrl + "?ticket=" + URLEncoder.encode(proxyTicket, "UTF-8") |
|
val proxyResponse = CommonUtils.getResponseFromServer(serviceUrl, "UTF-8") |
|
} |
|
---- |
|
====== |
|
|
|
[[cas-pt]] |
|
=== Proxy Ticket Authentication |
|
The `CasAuthenticationProvider` distinguishes between stateful and stateless clients. |
|
A stateful client is considered any that submits to the `filterProcessesUrl` of the `CasAuthenticationFilter`. |
|
A stateless client is any that presents an authentication request to `CasAuthenticationFilter` on a URL other than the `filterProcessesUrl`. |
|
|
|
Because remoting protocols have no way of presenting themselves within the context of an `HttpSession`, it isn't possible to rely on the default practice of storing the security context in the session between requests. |
|
Furthermore, because the CAS server invalidates a ticket after it has been validated by the `TicketValidator`, presenting the same proxy ticket on subsequent requests will not work. |
|
|
|
One obvious option is to not use CAS at all for remoting protocol clients. |
|
However, this would eliminate many of the desirable features of CAS. |
|
As a middle-ground, the `CasAuthenticationProvider` uses a `StatelessTicketCache`. |
|
This is used solely for stateless clients which use a principal equal to `CasAuthenticationFilter.CAS_STATELESS_IDENTIFIER`. |
|
What happens is the `CasAuthenticationProvider` will store the resulting `CasAuthenticationToken` in the `StatelessTicketCache`, keyed on the proxy ticket. |
|
Accordingly, remoting protocol clients can present the same proxy ticket and the `CasAuthenticationProvider` will not need to contact the CAS server for validation (aside from the first request). |
|
Once authenticated, the proxy ticket could be used for URLs other than the original target service. |
|
|
|
This section builds upon the previous sections to accommodate proxy ticket authentication. |
|
The first step is to specify to authenticate all artifacts as shown below. |
|
|
|
[source,xml] |
|
---- |
|
<bean id="serviceProperties" |
|
class="org.springframework.security.cas.ServiceProperties"> |
|
... |
|
<property name="authenticateAllArtifacts" value="true"/> |
|
</bean> |
|
---- |
|
|
|
The next step is to specify `serviceProperties` and the `authenticationDetailsSource` for the `CasAuthenticationFilter`. |
|
The `serviceProperties` property instructs the `CasAuthenticationFilter` to attempt to authenticate all artifacts instead of only ones present on the `filterProcessesUrl`. |
|
The `ServiceAuthenticationDetailsSource` creates a `ServiceAuthenticationDetails` that ensures the current URL, based upon the `HttpServletRequest`, is used as the service URL when validating the ticket. |
|
The method for generating the service URL can be customized by injecting a custom `AuthenticationDetailsSource` that returns a custom `ServiceAuthenticationDetails`. |
|
|
|
[source,xml] |
|
---- |
|
<bean id="casFilter" |
|
class="org.springframework.security.cas.web.CasAuthenticationFilter"> |
|
... |
|
<property name="serviceProperties" ref="serviceProperties"/> |
|
<property name="authenticationDetailsSource"> |
|
<bean class= |
|
"org.springframework.security.cas.web.authentication.ServiceAuthenticationDetailsSource"> |
|
<constructor-arg ref="serviceProperties"/> |
|
</bean> |
|
</property> |
|
</bean> |
|
---- |
|
|
|
You will also need to update the `CasAuthenticationProvider` to handle proxy tickets. |
|
To do this replace the `Cas20ServiceTicketValidator` with a `Cas20ProxyTicketValidator`. |
|
You will need to configure the `statelessTicketCache` and which proxies you want to accept. |
|
You can find an example of the updates required to accept all proxies below. |
|
|
|
[source,xml] |
|
---- |
|
|
|
<bean id="casAuthenticationProvider" |
|
class="org.springframework.security.cas.authentication.CasAuthenticationProvider"> |
|
... |
|
<property name="ticketValidator"> |
|
<bean class="org.apereo.cas.client.validation.Cas20ProxyTicketValidator"> |
|
<constructor-arg value="https://localhost:9443/cas"/> |
|
<property name="acceptAnyProxy" value="true"/> |
|
</bean> |
|
</property> |
|
<property name="statelessTicketCache"> |
|
<bean class="org.springframework.security.cas.authentication.SpringCacheBasedTicketCache"> |
|
<property name="cache"> |
|
<bean class="net.sf.ehcache.Cache" |
|
init-method="initialise" destroy-method="dispose"> |
|
<constructor-arg value="casTickets"/> |
|
<constructor-arg value="50"/> |
|
<constructor-arg value="true"/> |
|
<constructor-arg value="false"/> |
|
<constructor-arg value="3600"/> |
|
<constructor-arg value="900"/> |
|
</bean> |
|
</property> |
|
</bean> |
|
</property> |
|
</bean> |
|
----
|
|
|