[jboss-jira] [JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398773#comment-13398773 ] 

Brian Stansberry commented on ELY-1103:
---------------------------------------

Just to clarify: slave HCs have always had their management name as their default identity, i.e. the one that is used if no "username" is explicitly configured. That identity must be valid in the DC-side realm when local auth is not configured, or of course for the more usual case where the slave isn't on the same machine. Whatever has changed is in the way the local mechanism is being handled on the slave side, such that that identity is being presented via the JBOSS-LOCAL-USER mechanism whereas previous version slaves don't present it.

Letting the user explicitly configuring the username used by the slave was a way to make things easier by not requiring a separate entry in the realm for each slave. Configuring it wasn't meant to be required to get non-local-auth to work, not if your realm has entries for all your slaves.

I'll investigate what's changing on the slave side in the slave this is handled, keeping what you wrote in the description here about callbacks and handlers in mind as something to keep an eye out for.

> Special handling for JBOSS-LOCAL-USER server side authentication
> ----------------------------------------------------------------
>
>                 Key: ELY-1103
>                 URL: https://issues.jboss.org/browse/ELY-1103
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Server, SASL
>            Reporter: David Lloyd
>             Fix For: 1.1.0.Beta39
>
>
> If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails.  In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity.
> With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side.  Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name.  Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}.  Configurations which do not specify a user name will not have this problem.
> While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations.  If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name.  Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity.
> If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested.
> Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)