Misagh, thank you for your reply!
As for point 1 your where right in stating that I only sent {url}. So I
tested again with restricted registeredService entering
{url}/index.jsp and get the following:
HTTP 403 - No assertions found
Url shows following string:
https://whatever.example.com:8444/cas-client/index.jsp?TARGET=https%3A%2F%2Fwhatever.example.com%3A8444%2Fcas-client%2Findex.jsp&SAMLart=AAEp3wIcZoPsgCai1TKbsYUBc1eeKe2zStFM0RWqkp04ukDvpEjC8MMK
As for point 2, my question was oriented to FINAL result url, not
intermediate ones. So after sign on page the user should receive exactly
same url he/she entered, in this case
https://whatever.example.com:8444/cas-client/index.jsp?TARGET=https%3A%2F%2Fwhatever.example.com%3A8444%2Fcas-client%2Findex.jsp
Thanks Manfredo
El 09/10/14 a las 12:14, Misagh Moayyed escibió:
>
> /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 [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
