[ 
https://issues.apache.org/jira/browse/QPID-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7093:
-----------------------------
    Description: 
For some authentication providers, the id that represents a person is not human 
readable.  For instance, when using the Google OAuth2, the identities are 16 
digit numbers.  This present a usability problem in the web management console 
when viewing audit trail information createdBy/lastUpdateBy as the operator 
will have no reasonable way to find out the name of the user that created or 
updated an object.

Authentication Providers will have the ability to resolve a userid into a 
displayable name (QPID-7168).

There is a decision to be made about how the clients of the model get the 
displayable userid for a given object.

* The model could be extended to have 
displayableCreatedBy/displayedLastUpdatedBy derived attributes.  After 
recovery, once the services of the authentication provider are available, these 
attributes would somehow need to be populated. 
* The client of the model could make separate calls to the authentication 
provider to resolve userid to there displayable counterparts.  There could be 
an Authentication Provider operation to do this.   This seems ugly.
*  We could have displayableCreatedBy/displayedLastUpdatedBy as persisted 
values and have them be set on creation/update by taking the displayable name 
from the subject.  We would accept the fact that the displayable name could go 
stale.

  was:
For some authentication providers, the id that represents a person is not human 
readable.  For instance, when using the Google OAuth2, the identities are 16 
digit numbers.  This present a usability problem in the web management console 
when viewing audit trail information createdBy/lastUpdateBy as the operator 
will have no reasonable way to find out the name of the user that created or 
updated an object.

Authentication Providers should have a mechanism to return a human readable 
name for any valid user identity.  For some authentication providers, this 
might be implemented as a query.  For others, it might involve maintaining a 
cache that is populated as users use the Broker.


> Make the display of createdBy/lastUpdatedBy user information human readable
> ---------------------------------------------------------------------------
>
>                 Key: QPID-7093
>                 URL: https://issues.apache.org/jira/browse/QPID-7093
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Keith Wall
>             Fix For: qpid-java-6.1
>
>
> For some authentication providers, the id that represents a person is not 
> human readable.  For instance, when using the Google OAuth2, the identities 
> are 16 digit numbers.  This present a usability problem in the web management 
> console when viewing audit trail information createdBy/lastUpdateBy as the 
> operator will have no reasonable way to find out the name of the user that 
> created or updated an object.
> Authentication Providers will have the ability to resolve a userid into a 
> displayable name (QPID-7168).
> There is a decision to be made about how the clients of the model get the 
> displayable userid for a given object.
> * The model could be extended to have 
> displayableCreatedBy/displayedLastUpdatedBy derived attributes.  After 
> recovery, once the services of the authentication provider are available, 
> these attributes would somehow need to be populated. 
> * The client of the model could make separate calls to the authentication 
> provider to resolve userid to there displayable counterparts.  There could be 
> an Authentication Provider operation to do this.   This seems ugly.
> *  We could have displayableCreatedBy/displayedLastUpdatedBy as persisted 
> values and have them be set on creation/update by taking the displayable name 
> from the subject.  We would accept the fact that the displayable name could 
> go stale.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to