|
@@ -1,463 +0,0 @@
|
|
|
-[[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>
|
|
|
-----
|