Agreed that <access-control> isn't the appropriate location. For anyone
interested, here's a chat Darran and I had:
bstansberry: darranl: read your email
[09:05am] bstansberry: darranl: I'm still not clear on the boundary though
[09:06am] bstansberry: darranl: I can see how using a blacklisted
browser would mean you can't auth or that you can't map to *any* role
[09:07am] bstansberry: darranl: and I can see how the "any role" part
could be a config pain if it meant having to repeat some config for
[09:07am] bstansberry: plus create holes
[09:09am] bstansberry: darranl: I'm not really trying to advocate for
making this part of role mapping
[09:09am] bstansberry: more that I want to have a clearer conceptual
line for why something is in one place or another
[09:11am] darranl: Another item of configuration that I will pair with
this hopefully soon is the enablement of cross origin request handling,
that is also going to be http specific and will be dependent on this
banning of bad browsers so that we can ban a browser if we don't believe
it handles cross origin requests safely. Overall I believe this falls
under what can connect to HTTP not what can they do once connected and
that to me is the differentiator between mak
[09:11am] darranl: ing it a http management interface config item or
general access control item.
[09:13am] darranl: The remote address aspect however is something
different, that can apply equally to all management interface types and
I could see the location of an administrator being considered when
deciding what they can do.
[09:14am] bstansberry: darranl: ok, that's sounding better
[09:14am] bstansberry: darranl: the notion that the connection is
encrypted can follow that rationale as well
[09:14am] darranl: bstansberry, exactly
[09:15am] bstansberry: darranl: great; that's what I was looking for --
if it's protocol specific, it's not <access-control>
[09:16am] bstansberry: better stated -- if it's specific to a particular
management interface type
On 12/17/13 8:48 AM, Darran Lofthouse wrote:
The main purpose of the Jira issue is just for a blanked block on
bad browsers - it is not intended to take any part of 'If you use
Internet Explorer you can be a Monitor but if you use Firefox you can be
On 16/12/13 21:50, Brian Stansberry wrote:
> How does this related to the notion we've chatted about of incorporate
> environmental factors into role mapping?
> - Brian
> On 12/16/13 11:28 AM, Darran Lofthouse wrote:
>> Personally I don't believe this is something that belongs under access
>> control - this is not about changing what the user can access based on
>> their client or address this is about preventing HTTP connections from
>> known bad clients or locations.
>> As we enable cross origin request handling we are placing a certain
>> amount of trust in the users browser, one purpose of this change is to
>> prevent known buggy broswer versions from being able to connect to the
>> HTTP management interface.
>> Darran Lofthouse.
>> On 16/12/13 17:08, André Dietisheim wrote:
>>> I'm trying to come up with implementation for
where a user should be able to
>>> restrict access to the management service by IP and UserAgent. The
>>> filters are implemented and now I'm up to come up with the configuration
>>> options. I'm thus asking for input.
>>> From a noob (sorry, I'm not very intimate with wildfly/undertow yet)
>>> perspective <access-control> looks like a compelling tag to be nested
>>> into <management-interfaces><http-interface>. Even though
>>> <access-control> is used for RBAC currently, the code for it looks
>>> abstract enough to get reused.
>>> Any ideas?
>>> wildfly-dev mailing list
>> wildfly-dev mailing list
wildfly-dev mailing list
Principal Software Engineer
JBoss by Red Hat