[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=13398719#comment-13398719 ] 

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

Yesterday I was investigating JBEAP-10084 and the need for the must-be-removed workaround used to resolve JBEAP-9655. Both of these somewhat relate to this in that the JBOSS-LOCAL-USER mechanism is used, although those JIRAs relate to interaction with a legacy security realm. But while investigating I learned the relevant use cases so here's some information in case it's helpful:

1) The current CLI when authenticating presents an empty authenticationId. This results in LocalUserServer.defaultUser being used. That was "$local"; how that value for defaultUser got set I didn't research.

My guess is the way the CLI is written it doesn't prompt for a username/password until authenticating with an empty authenticationId fails. I didn't check.

2) I didn't try a previous release CLI to check if it was the same.

3) A current release slave HC provides an authenticationId that's the same as the slave's management name. This fails in an OOTB WildFly domain because the ManagementRealm is not configured with entries for the slaves. This is the cause of JBEAP-9655 and why the workaround of configuring the slave to use username="$local" works.

For a legacy security realm https://github.com/wildfly/wildfly-core/compare/master...bstansberry:local_auth_id solves the problem of broken OOTB behavior. Changing the legacy security realm's standard local auth config to add allowed-users="*" would do the same thing. Perhaps figuring out how the CLI is able to present an empty authenticationId and having the intra-domain logic do the same would also solve it.

4) An EAP 7.0.x slave HC presents an empty authenticationId. I don't know why, but of course the client side logic is different in EAP 7.0.x. Because it does, a 7.0.x slave is able to authenticate, same as the CLI can.

5) I didn't try an EAP 6 slave.

My personal opinion on this is things in the management area that used to "just work" should continue to just work. If that means the client side should not present a non-empty authenticationId because elytron-based authentication is going to insist on finding that id, that's fair enough, but we'll need to make sure our clients try to present the empty id first. It seems that the CLI and previous release slave HCs do that.

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