/[volute]/trunk/projects/grid/gms/doc/GMS.tex
ViewVC logotype

Diff of /trunk/projects/grid/gms/doc/GMS.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 5188 by major.brian, Thu Oct 11 23:06:02 2018 UTC revision 5189 by major.brian, Wed Oct 24 23:40:14 2018 UTC
# Line 5  Line 5 
5    
6  \ivoagroup{Grid and Web Services}  \ivoagroup{Grid and Web Services}
7    
8  \author{}  \author{Brian Major}
9  \author{}  \author{Patrick Dowler}
10    \author{Marco Molinaro}
11    
12  \editor{Brian Major}  \editor{Brian Major}
13    
14  % \previousversion[????URL????]{????Funny Label????}  % \previousversion[????URL????]{????Funny Label????}
15  \previousversion{This is the first public release}  \previousversion{This is the first public release}
16    
   
17  \begin{document}  \begin{document}
18  \begin{abstract}  \begin{abstract}
19    
20  The Group Membership Service (GMS) defines an service-oriented method of determining whether a user is a member of a group.  This information can be used to protect access to proprietary resources: clients can issue a call to GMS when an authorization decision needs to be made.  Proprietary resources can be any number of things such as data or services.  Because a single group can be used to protect multiple resources, GMS enables the creation of groups that represent teams with shared authorization.  GMS offers organizations an interoperable, flexible and scalable way of protecting a hetergenous set of resources.  The Group Membership Service (GMS) specification describes a service-oriented interface for determining whether a user is a member of a group.  This information can be used to protect access to proprietary resources: clients can issue a call to GMS when an authorization decision needs to be made.  Proprietary resources can be any number of things such as data, metadata or services.  Because a single group can be used to protect multiple resources, GMS enables the creation of groups that represent teams with common authorization rights.  GMS offers organizations an interoperable, flexible and scalable way of protecting a hetergenous set of resources.
21    
22  \end{abstract}  \end{abstract}
23    
# Line 76  Line 76 
76  Fig.~\ref{fig:archdiag} shows the role this document plays within the  Fig.~\ref{fig:archdiag} shows the role this document plays within the
77  IVOA architecture \citep{note:VOARCH}.  IVOA architecture \citep{note:VOARCH}.
78    
79    GMS can be used by any software that needs to check, for authorization purposes, whether a user is a member of group.  Because of this general use case, GMS cuts through all of the IVOA and lies squarely in the middle of the SHARING technical resource in the IVOA architecture diagram.
80    
81  \subsection{Use Cases}  \subsection{Use Cases}
82    
83    Asside from the main use case of restricting access to proprietary resources, GMS supports a number of other use cases, of both the user and system variety.
84    
85  \paragraph{Proprietary information} Restricting access to proprietary resources to certain users.  \paragraph{Proprietary information} Restricting access to proprietary resources to certain users.
86    
87  \paragraph{Homogeneity} Using the same mechanism to control access to proprietary resources in a data centre or in multiple data centres.  \paragraph{Homogeneity} Using the same mechanism to control access to proprietary resources in a data centre or in multiple data centres.
# Line 102  Line 106 
106    
107  \paragraph{User} An individual identified by authentication.  \paragraph{User} An individual identified by authentication.
108    
109  \paragraph{Group} A set of users who have access to a resource.  \paragraph{Group} A set of users.
110    
111  \paragraph{Grant} Giving a user authorization to access to a protected resource.  \paragraph{Grant} Authorizing access to a protected resource by assigning a group.
112    
113  \paragraph{Revoke} Taking away from a user access to a protected resource.  \paragraph{Revoke} Removing access to a protected resource by removing an assigned group.
114    
115  \paragraph{Owner} A user or group of users who may grant or revoke access to a specific resource.  \paragraph{Owner} A user or group of users who may grant or revoke access to a specific resource.
116    
# Line 119  Line 123 
123  \item When users try to access resources, the granting rules for that resource are evaluated at runtime. This is the \emph{authorization check}.  \item When users try to access resources, the granting rules for that resource are evaluated at runtime. This is the \emph{authorization check}.
124  \end{enumerate}  \end{enumerate}
125    
126  With these phases in mind and with the use cases defined, we can state that the goals of authorization is to:  With these phases in mind and with the use cases defined, we can state that the goals of authorization are to:
127    
128  \begin{itemize}  \begin{itemize}
129  \item To allow for restricted access certain resources: only a certain set of individuals may access certain resources.  \item To allow for restricted access certain resources: only a certain set of individuals may access certain resources.
# Line 133  Line 137 
137    
138  Why are groups a good model for authorization?  When a system needs to perform an \emph{authorization check} on a resource, it is trying to determine if the authenticated user is allowed access.  There are a number of options on how this can be accomplished.  Why are groups a good model for authorization?  When a system needs to perform an \emph{authorization check} on a resource, it is trying to determine if the authenticated user is allowed access.  There are a number of options on how this can be accomplished.
139    
140  A simple approach would be to add the identity of the user to the resource.  However, this is too restrictive as there may be multiple users who are allowed access.  So, we could instead add a list of user identities to the resource being protected.  This becomes a problem when there are two resources that need protecting by the same set of individuals.  This becomes difficult to maintain because a change in access rules (\emph{granting and revoking access}) would mean a change to multiple resources.  A simple approach would be to add the identity of the user to the resource.  However, this is too restrictive as there may be multiple users who are allowed access.  So, we could instead add a list of user identities to the resource being protected.  It becomes a problem when there are two resources that need protecting by the same set of individuals.  This becomes difficult to maintain because a change in access rules (\emph{granting and revoking access}) would mean a change to multiple resources.
141    
142  So, it becomes clear that this list of users needs to be detached and centralized so that it can be referenced and shared by multiple resources.  To do so, the list must become a single entity than can be referenced by a name.  And so, we must now have a named group of users.  So, it becomes clear that this list of users needs to be decoupled from the resource so that it can be referenced and shared by multiple resources.  To do so, the list must become a single entity than can be referenced by a name.  And so, we must now have a named group of users.
143    
144  But if there is a central repository of groups of users, we introduce other problems:  a single point of failure, and the inability to partition groups of users.  Thus, the \emph{location} of the group must accompany the group itself so that it is possible to have multiple collections of groups of users.  A central repository of groups of users would introduce other problems:  a single point of failure, and the inability to partition groups of users.  Thus, the \emph{location} of the group must accompany the group reference so that it is possible to have multiple collections of groups of users and multiple assiciated GMS services.
145    
146  Resources must then reference a group by a URI with a location and a name that is unique within that location.  This is called the Group Identifier.  Resources must then reference a group by a URI with a location and a name that is unique within that location.  This is called the Group Identifier.
147    
# Line 148  Line 152 
152  A Universal Group Identifier is an IVOID (\citep{std:VOID2}) used to uniquely identify groups.  For GMS, there are three important components to the group ID:  A Universal Group Identifier is an IVOID (\citep{std:VOID2}) used to uniquely identify groups.  For GMS, there are three important components to the group ID:
153    
154  \begin{enumerate}  \begin{enumerate}
155  \item \emph{The authority} This identifies the location or instance of the group membership service.  \item \emph{The authority}: This identifies the location or instance of the group membership service.
156  \item \emph{The path} Always 'gms', indicating that it is a group URI.  \item \emph{The path}: Always starting with '/gms', indicating that it is a group URI, with '/instance-name' which is the name of the particular GMS instance within the authority.
157  \item \emph{The query} Identifies the group within the authority.  The name of the group.  \item \emph{The query}: Identifies the group within the authority and instance.  The name of the group.
158  \end{enumerate}  \end{enumerate}
159    
160  Below is an example group identifier:  Below is an example group identifier:
161    
162  \begin{verbatim}  \begin{verbatim}
163  ivo://authority.example.com/gms/instance-name?groupName  ivo://authority.example.com/gms/instance1?groupName
164  \end{verbatim}  \end{verbatim}
165    
166  To resolve the host GMS service, lookup, in the Registry, the URL for resourceID:  To resolve the host GMS service URL, one would issue a query to RegTAP (\citep{std:RegTAP}) to find the accessURL in the interface for the authority:
167    
168  \begin{verbatim}  \begin{verbatim}
169  ivo://authority.example.com/gms/instance-name  SELECT access_url, security_method_id
170    FROM rr.interface
171    NATURAL JOIN rr.capability
172    NATURAL JOIN rr.resource
173    WHERE
174      ivoid = 'ivo://authority.example.com/gms/instance1' AND
175      standard_id = 'ivo://ivoa.net/std/gms#search-1.0'
176  \end{verbatim}  \end{verbatim}
177    
178  This may result in (for example):  This would result in an access URL capable of supporting a GMS search on the group 'groupName'.  For example:
179    
180  \begin{verbatim}  \begin{verbatim}
181  http://server.example.com/myGMS  http://server.example.com/myGMSImpl/search
182  \end{verbatim}  \end{verbatim}
183    
184  This is the URL to the GMS service with information on the group named 'groupName'.  \section{GMS Search API}
   
 TODO: From Marco: add non-normative section explaining how the registry is used to find the group service.  
   
 \section{Users}  
   
 The concept of users and user identity is core to group authorization.  When the owner of a resource would like to grant access to that resource to an individual, that individual must be referenced in some way.  When a system makes a call to a GMS service to determine if the user trying to access the resource is a member of a group, the GMS service needs to identify that user with the users in various groups.  
   
 The collection of data centres and astronomy institutes likely have many ways of identifying users.  They could be using external identity providers, they could have a local database of users, or may have a combination of these and other approaches.  Section~\ref(subsection:useridentity) has some recommendations on how to best design a user identity system, but this specification does not require such a design.  Instead, it requires simply that users can be uniquely identified within the scope of a GMS service's domain.  If a user identity reaches beyond the scope of a GMS service's domain (such as an X.500 distinguished name \citep{std:RFC1779}), then it, too, may be referenced by the service.  
   
 The list of officially supported authentication protocols can be found in the IVOA Single-Sign-On Profile: Authentication Mechanisms \citep{std:SSOAUTH}.  
   
 TBD...  
   
 \section{The group management service (GMS)}  
185    
186  The Group Membership Service (GMS) is a RESTful API that allows for the determination of whether a user is a member of a group.  The Group Membership Service (GMS) declares a RESTful API \citep{fielding00} that allows for the determination of whether a user is a member of a group.  This is the GMS search capability and is identified by the following standardID:
187    
188  TBD...  \begin{verbatim}
189    ivo://ivoa.net/std/gms#search-1.0
190  \subsection{API definition}  \end{verbatim}
191    
192  Functionally required:  Within this capability, there are two functions:
193  \begin{itemize}  \begin{itemize}
194  \item boolean isMember(Group, User)  \item \emph{boolean isMember(Group, User)}: Return true if User is a member of Group.
195  \item list<Group> getMemberships(User)  \item \emph{list<Group> getMemberships(User)}: Return the list of Groups of which User is a member.
196  \end{itemize}  \end{itemize}
197    
198  Group Membership System RESTful \citep{fielding00} API  Group Membership System RESTful API
199    
200  Mandatory Support:  Mandatory Support:
201  \begin{verbatim}  \begin{verbatim}
# Line 226  Line 222 
222    
223  TBD...  TBD...
224    
225    \section{Users}
226    
227    The concept of users and user identity is core to group authorization.  When a system makes a call to a GMS service to determine if the user trying to access the resource is a member of a group, the GMS service needs to identify that user with the users in various groups.
228    
229    The collection of data centres and astronomy institutes likely have many ways of identifying users.  They could be using external identity providers, they could have a local database of users, or may have a combination of these and other approaches.  This specification does not require such a design.  Instead, it requires simply that users can be uniquely identified within the scope of a GMS service's domain.  If a user identity reaches beyond the scope of a GMS service's domain (such as an X.500 distinguished name \citep{std:RFC1779}), then it, too, may be referenced by the service.
230    
231    The list of officially supported authentication protocols can be found in the IVOA Single-Sign-On Profile: Authentication Mechanisms \citep{std:SSOAUTH}.  However, these protocols are
232    
233    \subsection{User Identity}
234    
235    TBD...
236    
237  \section {Implementation}  \section {Implementation}
238    

Legend:
Removed from v.5188  
changed lines
  Added in v.5189

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26