hdeadman
committed by
Marcus Da Coregio
Marcus Da Coregio
parent
baf2c98c9f
commit
b4d3ac6665
@@ -49,6 +49,7 @@
|
||||
*** xref:servlet/authentication/anonymous.adoc[Anonymous]
|
||||
*** xref:servlet/authentication/preauth.adoc[Pre-Authentication]
|
||||
*** xref:servlet/authentication/jaas.adoc[JAAS]
|
||||
*** xref:servlet/authentication/cas.adoc[CAS]
|
||||
*** xref:servlet/authentication/x509.adoc[X509]
|
||||
*** xref:servlet/authentication/runas.adoc[Run-As]
|
||||
*** xref:servlet/authentication/logout.adoc[Logout]
|
||||
|
||||
@@ -0,0 +1,463 @@
|
||||
[[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 the ``GrantedAuthority``s.
|
||||
* 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.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.jasig.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.jasig.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, JASIG'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.jasig.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 JASIG'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.jasig.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.jasig.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:
|
||||
|
||||
====
|
||||
.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 `filterProcessUrl` of the `CasAuthenticationFilter`.
|
||||
A stateless client is any that presents an authentication request to `CasAuthenticationFilter` on a URL other than the `filterProcessUrl`.
|
||||
|
||||
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 `filterProcessUrl`.
|
||||
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.jasig.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.EhCacheBasedTicketCache">
|
||||
<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>
|
||||
----
|
||||
@@ -16,6 +16,7 @@ These sections focus on specific ways you may want to authenticate and point bac
|
||||
* xref:servlet/authentication/passwords/index.adoc#servlet-authentication-unpwd[Username and Password] - how to authenticate with a username/password
|
||||
* xref:servlet/oauth2/login/index.adoc#oauth2login[OAuth 2.0 Login] - OAuth 2.0 Log In with OpenID Connect and non-standard OAuth 2.0 Login (i.e. GitHub)
|
||||
* xref:servlet/saml2/index.adoc#servlet-saml2[SAML 2.0 Login] - SAML 2.0 Log In
|
||||
* xref:servlet/authentication/cas.adoc#servlet-cas[Central Authentication Server (CAS)] - Central Authentication Server (CAS) Support
|
||||
* xref:servlet/authentication/rememberme.adoc#servlet-rememberme[Remember Me] - how to remember a user past session expiration
|
||||
* xref:servlet/authentication/jaas.adoc#servlet-jaas[JAAS Authentication] - authenticate with JAAS
|
||||
* xref:servlet/authentication/preauth.adoc#servlet-preauth[Pre-Authentication Scenarios] - authenticate with an external mechanism such as https://www.siteminder.com/[SiteMinder] or Java EE security but still use Spring Security for authorization and protection against common exploits.
|
||||
|
||||
@@ -145,5 +145,6 @@ If not configured, a status code 200 is returned by default.
|
||||
- xref:servlet/test/mockmvc/logout.adoc#test-logout[Testing Logout]
|
||||
- xref:servlet/integrations/servlet-api.adoc#servletapi-logout[`HttpServletRequest.logout()`]
|
||||
- xref:servlet/authentication/rememberme.adoc#remember-me-impls[Remember-Me Interfaces and Implementations]
|
||||
- Documentation for the xref:servlet/appendix/namespace.adoc#nsa-logout[ logout element] in the Spring Security XML Namespace section
|
||||
- xref:servlet/exploits/csrf.adoc#servlet-considerations-csrf-logout[Logging Out] in section CSRF Caveats
|
||||
- Documentation for the xref:servlet/appendix/namespace/http.adoc#nsa-logout[logout element] in the Spring Security XML Namespace section
|
||||
|
||||
Reference in New Issue
Block a user