[
https://issues.apache.org/jira/browse/GUACAMOLE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman reassigned GUACAMOLE-457:
---------------------------------------
Assignee: Nick Couchman (was: Carl Harris)
> 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
>
> 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)
