12:48 p.m.
[
https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s...
]
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:loca... 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)
3372
days inactive
3372
days old
0 comments
1 participants
participants (1)
-
Brian Stansberry (JIRA)