Well, that is progress to some degree.
Something is missing in your configuration. You should be redirected to CAS with a TARGET parameter, and then back to the app after login with a TAGET and a SAMLart. The validation portion should take both of those parameters and talk to CAS to verify, at which time you will be issues back the assertion. Review your logs and see which step is not executing and/or failing. and yes, you (the app) should receive the TARGET parameter exactly as it was received. If you are not getting values back in the url, its either an issue with parameter encoding or its a bug that is yet to be discovered! If you do not want to receive certain portions of that url back, simply dont send them to CAS. From: Manfredo Hopp [mailto:[email protected]] Sent: Thursday, October 9, 2014 10:40 AM To: [email protected] Subject: Re: [cas-user] SAML extracted service doesnt match exact registered service in CAS4 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 <https://whatever.example.com:8444/cas-client/index.jsp?TARGET=https%3A%2F %2Fwhatever.example.com%3A8444%2Fcas-client%2Findex.jsp&SAMLart=AAEp3wIcZo PsgCai1TKbsYUBc1eeKe2zStFM0RWqkp04ukDvpEjC8MMK> &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 its 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] <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" /> 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%2Fwhateve r.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.Saml11AuthenticationFilt er</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.Cas20ProxyReceivingTicket ValidationFilter</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</f ilter-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] <mailto:[email protected]> as: [email protected] <mailto:[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] <mailto:[email protected]> as: [email protected] <mailto:[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] <mailto:[email protected]> as: [email protected] <mailto:[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
