CAS proxy receptor URL protected

[Richard]

In OWF 7.0.1, when using CAS, OWFCasBeans.xml defines a CAS proxy ticket receptor at /secure/receptor (with "owf" context, it is /owf/secure/receptor).  However, none of the OWFsecurityContext*.xml files specify a rule to make this URL exempt from authentication.  I believe that there should be a line as follows:

 

<sec:intercept-url pattern="/secure/receptor" filters="none" />

 

This will allow the CAS server to communicate with the proxy ticket receptor without having to authenticate itself with itself.  I'm not sure if the receptor URL is traditionally authenticated or not, but I think there's no need to require authentication for it?

[Tina Coleman]

The handshake between CAS and the application will only occur if it's done over HTTPs with a trusted connection between the two servers.  Although OWF ships with CAS alongside it, CAS is a separate service which acts as if it is upon a separate server.  So it's not actually authenticating itself with itself - it's doing a ticket exchange with OWF, which could be just one of many services using it as a single sign-on.  If you'd like further details, check out this walkthrough of the handshakes on https://wiki.jasig.org/plugins/servlet/mobile#content/view/29131352.

Now, that's a server-to-server trust - it doesn't require an authenticated ROLE_USER or ROLE_ADMIN.  I'm slacking this evening - are you saying you're seeing something other that a requirement for https?

Tina

--
You received this message because you are subscribed to the Google Groups "ozoneplatform-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ozoneplatform-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard]

I'm believe I'm in agreement with what you're saying, but there's something else to this.  I'll explain the situation I think I'm experiencing more clearly, and you can let me know your thoughts.

 

1. User browses to Ozone.

2. Ozone redirects to CAS server (e.g. https://<cas host>/cas/login?service=https://<ozone host>/owf/j_spring_cas_security_check).

3. User provides credentials to CAS.

4. CAS authenticates user and redirects to https://<ozone host>/owf/j_spring_cas_security_check?ticket=<ST ticket>

5. Ozone validates CAS ticket by calling https://<cas host>/cas/serviceValidate?ticket=<ST ticket>&service=https://<ozone host>/owf/j_spring_cas_security_check&pgtUrl=https://<ozone host>/owf/secure/receptor.

6. CAS attempts to send proxy granting ticket (PGT) to https://<ozone host>/owf/secure/receptor.

7. The "secure/receptor" URL is protected by Ozone (requires CAS authentication).  So when CAS executes HTTP request to send PGT over, it has to authenticate with CAS (itself).  In my circumstance, CAS is not based upon PKI cert, so CAS cannot authenticate itself and cannot send the PGT.  Solution is to unprotect the "secure/receptor" URL - not require CAS authentication on this URL.  However, it is still protected by one-way SSL (HTTPS).

 

 

Richard

[Tina Coleman]

​Technically, it doesn't require CAS authentication, but I think you're saying a line like the below in the securityContext.xml file would cause the system to bounce back and forth back to CAS to verify that someone has one of ROLE_USER, etc...  that that's what you're seeing in your environment. 

<sec:intercept-url pattern="/**" access="ROLE_USER,ROLE_ORG_STEWARD,ROLE_ADMIN" requires-channel="https" />

So, you'd suggest that the SecurityContext.xml file might have a pattern above the /** which doesn't require a role-based access for the receptor endpoint, but do require https...

Try it - see if it works (or just indicate that you've already done so...)  I will say, OWF has used CAS both in cert-based and in non-cert based scenarios and not run into the issue you're describing.  The out-of-the-box scenario for OWF for a long-time would use certs if they were available, and fail over to a login screen deployed in the CAS war.  Historically, the securityContext file mostly ignored that CAS was doing the handshake, except to include the beans needed for CAS at the bottom.  Meaning, the interceptors at the top didn't truly have knowledge of...

FYI: the ozp-security project (https://github.com/ozoneplatform/ozp-security) shows the original configuration files, but you have to dig back through the commit history.  The team supporting the GOSS efforts has cleaned things up a bit since the open-source OWF release, and CAS is no longer directly supported in the bean configurations.  Can still be added as an auth/auth mechanism, of course, but no longer provided directly as an example.

Tina Coleman

NEXTCENTURYCORPORATION
7075 Samuel Morse Drive, Suite 250 | Columbia, MD 21046
m 443.545.3100 | f 443.285.0799 |www.nextcentury.com
 

---

From: ozonepla...@googlegroups.com <ozonepla...@googlegroups.com> on behalf of Richard <rks...@gmail.com>
Sent: Wednesday, February 4, 2015 8:22 PM
To: ozonepla...@googlegroups.com
Subject: Re: CAS proxy receptor URL protected

 

[Richard]

Tina,
 
Thanks for the help on this.  I figured out what was going on.
 
The CAS proxy receptor works despite being a protected resource (requiring ROLE_USER or ROLE_ADMIN) because it's just a servlet filter.  My confusion arose from me browsing to https://<ozone host>/owf/secure/receptor, which resulted in my browser being directed to the CAS login page.  This is actually irrelevant because the filter that receives the proxy ticket would still be executed despite me eventually being directed to the login page.
 
So the bottom line is that you are correct, and no special rules are required for the CAS proxy receptor in the securityContext.xml.  However, in my environment I may choose to include this rule for completeness:

<sec:intercept-url pattern="/secure/receptor" access="ROLE_ANONYMOUS" />
 
Since you mentioned CAS has been removed from the Ozone bundle, this is kind of a moot point for anything after Ozone 7.0.1.
 
 
Richard