[jira] Updated: (SLING-1554) Restore support for authentication-handler-specific Credentials

["Ray Davis (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Davis updated SLING-1554:
-----------------------------

    Affects Version/s: JCR Jackrabbit Server 2.0.6

> Restore support for authentication-handler-specific Credentials
> ---------------------------------------------------------------
>
>                 Key: SLING-1554
>                 URL: https://issues.apache.org/jira/browse/SLING-1554
>             Project: Sling
>          Issue Type: Improvement
>          Components: Commons
>    Affects Versions: JCR Jackrabbit Server 2.0.6
>            Reporter: Ray Davis
>
> Jackrabbit 1.6.2's standard repository login accepted any implementation of Credentials. This let Sling authentication plugins define their own Credentials classes, and the OpenID Authentication extension creates a component-specific Credentials class in its "extractCredentials" method and checks it in "canHandle".
> Jackrabbit 2.0 changed the AbstractLoginModule to reject Credentials classes other than SimpleCredentials and GuestCredentials. As a result, by default "getCredentials" will return null if an AuthenticationHandler supplied any other implementation.
> A superclass of DefaultLoginModule has two ways around this: to override getCredentials() or to override supportCredentials(). Currently, Sling's PluggableDefaultLoginModule overrides getCredentials but does so only to allow for Sling's TrustedCredentials class.
> Either the PluggableDefaultLoginModule should let LoginModulePlugin implementations use their own Credentials classes (by doing the usual loop around "canHandle(creds)"), or the restriction should be documented and the OpenID extension changed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.