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

[Darran Lofthouse (JIRA)]

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

Darran Lofthouse commented on ELY-1103:
---------------------------------------

Code could have moved on within the last week but the initial reason for running into this issue was: -

In prior releases the mechanism was configured to be quiet on the client side and it would remain quiet, it would not use the supplied CallbackHandler to request an authentication ID so it would not send one, this allowed server side to then fallback and use the default name it is configured with which is '$local'.

In the later Elytron AuthenticationClient code the configuration to make the mechanism quiet is only set if we have no username defined in the configuration and no callback handler is available to request one, the slave process always provides a CBH as we don't know which authentication mechanisms will be offered by the server.

There are still some other areas of local authentication to work through but in the slave host controller process we could actually look into removing the callback handler entirely - i.e. the authentication context and authentication configuration APIs are a set of APIs that allow names and passwords to be specified. (We would need to check the correct precedence) but in theory if the slave HC has a password defined it could obtain the current ACtx and resolve the ACfg and apply the username and password and at the same time disable local auth.  If a password is not set then take no action and send no CBH - then you will get quiet local authentication.

Generally the CBH is better suited to environments where we want user interaction e.g. the CLI - but in processes like this that know everything they already know we could move from the CBH and use the ACtx and ACfg directly.

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