[jboss-jira] [JBoss JIRA] (WFLY-430) Update the whoami operation to output additional information when called with verbose=true

[Darran Lofthouse (JIRA)]

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

Darran Lofthouse commented on WFLY-430:
---------------------------------------

Jira discussion re implicatios of expanding this operation: -

{noformat}
<darranl> bstansberry, we should discuss what else we want output from the whoami operation (if anything) https://issues.jboss.org/browse/WFLY-430
<bstansberry> darranl: hmmm
<darranl> That operation could give the potential to verify a - the loaded groups and b - the roles they map to in context
<bstansberry> I'm reluctant to expose role-mapping stuff in general purpose ops like that
<bstansberry> darranl: my concern is that "role based" permissions are an implementation details that in the long run I don't want to require
<bstansberry> i.e. they are our default impl of a pluggable SPI
<bstansberry> still, there are going to be demands for role mapping data; e.g. we got a request for that stuff as part of the audit logging output
<darranl> bstansberry, I wonder it the pluggable SPI could add information to the whoami output 
<bstansberry> darranl: yeah. so the trick is to provide users with the info they without providing a guarantee that the data will be present
<darranl> bstansberry, my thought is that if there is a way for this info to be seen a lot of testing can be performed to verify that the mappings are correct without having to rely on operations succeeding or failing i.e. testing of mapping can be split from testing of enforcement 
<Ladicek> my thoughts exactly -- I hope that we will have the whoami operation for roles mapping testing
<bstansberry> darranl: there will be management resource related to access-control, so we can expose ops like that in those resource
<bstansberry> for sure we should
<bstansberry> I think the management resources related to access control should have stuff in their address that indicates it's RBAC vs something else
<darranl> other ops would be just as useful, I was just thinking about expanding on the existing op but maybe we could have ops specific to the impl of the SPI?  That way if you change the imp you change the ops?
<bstansberry> yes, I think there should be RBAC-specific ops
<bstansberry> so some other impl would not register the relevant resources
<bstansberry> user/group->role mapping is related to RBAC, not to authorization in general
<bstansberry> so the resources related to that should be in an RBAC section of the resource tree, separate from other stuff that's more generic
<darranl> Ok that makes sense
<bstansberry> including data in whoami is ok too (maybe) it's just that it's hard to describe the operation output
<bstansberry> i.e. :read-operation-description won't know the structure of what the SPI impl will add
* bstansberry is not sure how much he care about that!
<Ladicek> the SPI can also provide the description, no?
<darranl> I am not sure either ;-)  But provided we have some operation to query it I am not set on it needing to be in whoami anyway
<bstansberry> Ladicek: perhaps. it just gets more complicated, but it might be possible
<darranl> The most important part of whoami was so that remote clients could identify who they authenticated as - with browsers and the local auth mechanism clients did not have a way to identify the authenticated user
{noformat}
                
> Update the whoami operation to output additional information when called with verbose=true
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-430
>                 URL: https://issues.jboss.org/browse/WFLY-430
>             Project: WildFly
>          Issue Type: Task
>          Components: CLI, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> I need to review if this is feasible but there are a number of reports coming in where end users believe their server is not secured because our local / silent mechanism is working so quietly.
> Initially this issue was to just output the authentication mechanism used however with the addition of access control to WildFly 8 there is additional information that will be useful: -
>  - Authentication Mechanism
>  - Current role membership (May need to take into account the address i.e. what roles do I have at this address)
>  - Additional items that may be used in an authorization decision? e.g. Confidential connection, time, address of client (verify a local connection does appear local)
> Anything else that is included in the audit?
> Could some of these attributes in a response be considered sensitive?  Return everything except the sensitive ones.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira