[jira] [Updated] (GUACAMOLE-457) CAS authentication provider omits login URI

["Nick Couchman (JIRA)" <ji...@apache.org>]

     [ 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)