11:08 a.m.
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é
11:28 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:50 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
8:48 a.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
9:25 a.m.
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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4623
days inactive
4624
days old
4 comments
3 participants
participants (3)
-
André Dietisheim -
Brian Stansberry -
Darran Lofthouse