I have observed that pattern matching the services as *strings* seems to be
a source of confusion for newcomers to CAS when setting up the service
registry. I think having a matching syntax that operated on URLs would be
more intuitive.
When I implemented a service manager for my txcas project [1], I took this
approach. An entry looks like this:
{"name": "Service A", "scheme": "*", "netloc": "127.0.0.1:9801", "path":
"/", "child_paths": true, "required_params": null}
The syntax is not that great, but it breaks the URL into pieces so that
there isn't much confusion with what you are actually allowing or
prohibiting. Also, default ports are recognized, so that (for example) '
https://www.example.com/foo' *and* 'https://www.example.com:443/foo' are
*both* matched. This can be achieved by a regex match, but it is not
always intuitive that a match is initially failing due to an explicity
specified port.
Thanks,
Carl Waldbieser
[1]
https://github.com/cwaldbieser/txcas/blob/master/txcas/json_service_manager.py
On Oct 9, 2014 11:20 AM, "Misagh Moayyed" <[email protected]> wrote:
> *1. shoudnt SAML be able to validate exact match?*
>
>
>
> But it IS doing an exact match, right? You authorized {url}/index.jsp and
> the /login endpoint just received {url}. That is going to fail with a
> not-authorized message because the match cannot complete. This is more of a
> regex question than CAS or SAML. The underlying code wants to eat the whole
> string and match the entire “region” (calls matches() rather than find())
> So it’s up you to relax the rule.
>
>
> *2. should validation result bring requested page WITHOUT query
> parameters?*
>
>
>
> So this is interesting; While the query strings should be passed to CAS
> during the validation call (because the client makes no assumptions on your
> part), I am wondering if there is a need for us to abstract way the
> matching concept during validation. While we require exact matches per the
> protocol, there have been times where we had to relax that rule a little
> bit, to ignore query strings, or to sanitize the url for default ports, or
> simply remove trailing “/” at the end of the validation url, etc.
>
>
>
> Granted, these are edge cases and very few, but there may some value in
> exposing that bit?
>
>
>
> *From:* Manfredo Hopp [mailto:[email protected]]
> *Sent:* Thursday, October 9, 2014 7:51 AM
> *To:* [email protected]
> *Subject:* [cas-user] SAML extracted service doesnt match exact
> registered service in CAS4
>
>
>
>
>
> Hi, in CAS4 using SAML accessing a URL with an exact match of registered
> service returns Application not Autorized to use Cas.
> With more permissive regexpr Cas allows usage but still with annoynig url
> with query parameters.
>
> Use case:
>
> -Take cas4 overlay add saml support as of
> https://wiki.jasig.org/display/CASUM/SAML+Support+in+CAS+4
> -Build simple client with filter entries as shown below
> -add <property name="serviceId" value="^https?://
> whatever.example.com:8444/cas-client/index.jsp" /> as registered service-
> -In browser: https://whatever.example.com:8444/cas-client/index.jsp
>
> results in:
> cas login page with url
> https://whatever.example.com:8444/cas/login?TARGET=https%3A%2F%2Fwhatever.example.com%3A8444%2Fcas-client%2F
> whith user password/input throws following result:
>
> Application Not Authorized to Use CAS
>
> *Conclusion*: only with regular expression ^https?://
> whatever.example.com:8444/cas-client/.* can I authorize a page,
> showing this result URL.
>
> https://whatever.example.com:8444/cas-client/?TARGET=https%3A%2F%2Fwhatever.example.com%3A8444%2Fcas-client%2F
>
> *Questions*: 1. shoudnt SAML be able to validate exact match?
> 2. should validation result bring requested page
> WITHOUT query parameters?
>
>
> Appreciate any comments
>
> Manfredo Hopp
>
>
> -*cas-client filter entries*
>
> <filter>
> <filter-name>CAS Authentication Filter</filter-name>
>
> <filter-class>org.jasig.cas.client.authentication.Saml11AuthenticationFilter</filter-class>
>
> <!--filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class-->
> <init-param>
> <param-name>casServerLoginUrl</param-name>
> <param-value>https://whatever.example.com:8444/cas/login
> </param-value>
> </init-param>
> <init-param>
> <param-name>serverName</param-name>
> <param-value>https://whatever.example.com:8444</param-value>
> </init-param>
> </filter>
> <filter>
> <filter-name>CAS Validation Filter</filter-name>
>
> <filter-class>org.jasig.cas.client.validation.Saml11TicketValidationFilter</filter-class>
>
> <!--filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class-->
> <init-param>
> <param-name>casServerUrlPrefix</param-name>
> <param-value>https://whatever.example.com:8444/cas
> </param-value>
> </init-param>
> <init-param>
> <param-name>serverName</param-name>
> <param-value>https://whatever.example.com:8444</param-value>
> </init-param>
> <init-param>
> <param-name>redirectAfterValidation</param-name>
> <param-value>true</param-value>
> </init-param>
> <init-param>
> <!--
> Adjust to accommodate clock drift between client/server.
> Increasing tolerance has security consequences, so it is
> preferable to
> correct the source of clock drift instead.
> -->
> <param-name>tolerance</param-name>
> <param-value>5000</param-value>
> </init-param>
> </filter>
>
> <filter>
> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
>
> <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
> </filter>
>
> <filter>
> <filter-name>CAS Assertion Thread Local Filter</filter-name>
>
> <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class>
> </filter>
> <!-- Other filters as needed -->
>
>
> <filter-mapping>
> <filter-name>CAS Authentication Filter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>CAS Validation Filter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>CAS Assertion Thread Local Filter</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
>
>
> --
>
> You are currently subscribed to [email protected] as:
> [email protected]
>
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
> --
> You are currently subscribed to [email protected] as:
> [email protected]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
