[ https://issues.apache.org/jira/browse/GUACAMOLE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Couchman updated GUACAMOLE-457: ------------------------------------ Priority: Minor (was: Major) > CAS authentication provider omits login URI > ------------------------------------------- > > Key: GUACAMOLE-457 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-457 > Project: Guacamole > Issue Type: Bug > Affects Versions: 0.9.13-incubating > Reporter: Carl Harris > Assignee: Nick Couchman > Priority: Minor > > According to the CAS 2.0 protocol specification > (https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-V2-Specification.html) > the URI for obtaining a ticket for an unauthenticated user is derived from > the base URI by appending `/login`. In the current source for CAS > authentication provider, the URI that is used for this purpose is the base > URI (i.e. whatever URL is configured as the value for the > `cas-authorization-endpoint` property). This prevents successful > authentication using the provider with a protocol-compliant CAS server. > Attempting to use the login URL as the value of the > `cas-authorization-endpoint` property as a workaround subsequently fails when > the validation URI is appended to the URL; this results in a URL that ends > with the path `/login/proxyValidate` which is incorrect and violates the CAS > protocol. > It seems that the solution could be as simple as appending `/login` to the > authorization endpoint URI in the AuthorizationServiceProvider, when the > CASTicketField object is constructed. Indeed a simple patch using this > approach was tested and confirmed to work properly with a protocol-compliant > CAS server implementation. > However, this approach allows some protocol specifics to leak into the > AuthorizationServiceProvider which otherwise relies on abstractions that wrap > classes of the Apereo CAS client. It does not appear that there is an > appropriate class/method provided by the CAS client library to construct the > login URL from the base URL. Perhaps simply adding a method to the > extension's TicketValidationService for this purpose would be reasonable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)