You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2016/07/11 15:55:11 UTC
[jira] [Comment Edited] (QPID-7303) [Java Broker] Add REST service
listing authenticated user principals and groups
[ https://issues.apache.org/jira/browse/QPID-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15371025#comment-15371025 ]
Keith Wall edited comment on QPID-7303 at 7/11/16 3:54 PM:
-----------------------------------------------------------
Services should part of the versioned API just like the model API. I like the suggestion that {{/api/<version>/}} would be somehow subdivided to separate the model API from other things. We might have {{/api/<version>/model/broker/...}} etc and {{/api/<version>/services/whoami}}. We also need a cleaner way to separate services that are accessible before authentication ({{service/sasl}}) and those only after. Services should be self-describing too, so their documentation can be generated automatically. I think such a change would be appropriate for a major version (i.e. v7).
For v6.1/2, I think the proposed patch is along the right lines:
* the response should separate the authenticated user from groups. e.g. { username: "keith", groups: ["admin", "dev", "messaging"]}
** For the username, the implementation will need to find the {{AuthenticatedUser}} within the Subject.
** For the groups, the implementation will need to find the Principals implementing {{GroupPrincipal}}.
The WMC will be changed to call the {{whomami}} service, once at login. I think it will be acceptable that the user needs to logoff and logon again if their group membership changes after they have established a session. {{whoami}} will also be usable by programatic users of the REST API, who are using preemptive authentication.
was (Author: k-wall):
Services should part of the versioned API just like the model API. I like the suggestion that {{/api/<version>/}} would be somehow subdivided to separate the model API from other things. We might have {{/api/<version>/model/broker/...}} etc and {{/api/<version>/services/whoami}}. We also need a cleaner way to separate services that are accessible before authentication ({{service/sasl}}) and those only after. I think such a change would be appropriate for a major version (i.e. v7).
For v6.1/2, I think the proposed patch is along the right lines:
* the response should separate the authenticated user from groups. e.g. { username: "keith", groups: ["admin", "dev", "messaging"]}
** For the username, the implementation will need to find the {{AuthenticatedUser}} within the Subject.
** For the groups, the implementation will need to find the Principals implementing {{GroupPrincipal}}.
The WMC will be changed to call the {{whomami}} service, once at login. I think it will be acceptable that the user needs to logoff and logon again if their group membership changes after they have established a session. {{whoami}} will also be usable by programatic users of the REST API, who are using preemptive authentication.
> [Java Broker] Add REST service listing authenticated user principals and groups
> -------------------------------------------------------------------------------
>
> Key: QPID-7303
> URL: https://issues.apache.org/jira/browse/QPID-7303
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments: 0001-Add-Whoami-servlet.patch
>
>
> Information about authenticated user groups should be available to the user via special REST service.
> These new REST API is required for implementation of query and dashboard sharing functionality: user should be able to share queries/dashboards among groups he/she belongs to.
> AP I should provide information about logged user (who am I):
> * name
> * groups
> * it can be extended later to provide moreuser details
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org