[wildfly-dev] WFLY-705: how should access restrictions get configured?

[Brian Stansberry]

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 
every role
[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 known
> 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
> SuperUser'.
>
> Regards,
> Darran Lofthouse.
>
>
> On 16/12/13 21:50, Brian Stansberry wrote:
>> Darran,
>>
>> 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.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 16/12/13 17:08, André Dietisheim wrote:
>>>> Hi
>>>>
>>>> I'm trying to come up with implementation for
>>>> https://issues.jboss.org/browse/WFLY-705 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?
>>>>
>>>> Cheers
>>>> André
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat