Thank you Carl for your reply As far as my understanding about regular expressions is, the following is valid:
^https?://whatever.example.com:8444/cas-client/index.jsp <http://whatever.example.com:8444/cas-client/index.jsp> Nevertheless I agree with you about first glance confusion and take into account your advice. Thanks Manfredo El 09/10/14 a las 13:07, Carl Waldbieser escibió: > > 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 > <http://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] > <mailto:[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] > <mailto:[email protected]>] > *Sent:* Thursday, October 9, 2014 7:51 AM > *To:* [email protected] <mailto:[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 > <http://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/.* > <http://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 [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > > To unsubscribe, change settings or access archives, > seehttp://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed [email protected] > <mailto:[email protected]> as:[email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, > seehttp://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
