/[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 5734 by major.brian, Fri Feb 21 23:14:37 2020 UTC revision 5735 by major.brian, Sat Feb 22 01:08:11 2020 UTC
# Line 51  Line 51 
51  Interoperability aside, GMS describes a simple, general, maintainable, and scalable approach to performing authorization, and so is a recommended architectural pattern for managing access to proprietary resources.  Interoperability aside, GMS describes a simple, general, maintainable, and scalable approach to performing authorization, and so is a recommended architectural pattern for managing access to proprietary resources.
52    
53  \subsection{Proprietary resources}  \subsection{Proprietary resources}
54    \label{subsec:propresources}
55    
56  Most facilities have a period of time in which only the Principal Investigator and the associated team has access to observation metadata and data files.  Even without a proprietary period, time is required to verify and validate observations before they can be made public.  Most facilities have a period of time in which only the Principal Investigator and the associated team has access to observation metadata and data files.  Even without a proprietary period, time is required to verify and validate observations before they can be made public.
57    
# Line 61  Line 62 
62  In these ways and others, proprietary resources exist.  For these to be made available to those with authorization, we require a consistent way of performing authorization checks.  In these ways and others, proprietary resources exist.  For these to be made available to those with authorization, we require a consistent way of performing authorization checks.
63    
64  \subsection{Role within the VO Architecture}  \subsection{Role within the VO Architecture}
65    \label{subsec:roleinarch}
66    
67  \begin{figure}  \begin{figure}
68  \centering  \centering
# Line 76  Line 78 
78  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 purpose functionality, GMS slices through all IVOA standards and lies in the middle of the SHARING technical resource in the IVOA architecture diagram.  Indeed, GMS allows for the sharing of proprietary resources to a limited audience.  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 purpose functionality, GMS slices through all IVOA standards and lies in the middle of the SHARING technical resource in the IVOA architecture diagram.  Indeed, GMS allows for the sharing of proprietary resources to a limited audience.
79    
80  \subsection{Use Cases}  \subsection{Use Cases}
81    \label{subsec:usecases}
82    
83  Aside 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.  Aside 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    
# Line 135  Line 138 
138  \section{Groups}  \section{Groups}
139    
140  \subsection{Why Groups?}  \subsection{Why Groups?}
141    \label{subsec:whygroups}
142    
143  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.
144    
# Line 149  Line 153 
153  Systems must use the information in the group identifier to determine if the user is a member of the group.  Because the location may be outside of the immediate vicinity of the resource, this query must be performed in a standard and accessible manner and so is defined as a RESTful interface to group membership.  Systems must use the information in the group identifier to determine if the user is a member of the group.  Because the location may be outside of the immediate vicinity of the resource, this query must be performed in a standard and accessible manner and so is defined as a RESTful interface to group membership.
154    
155  \subsection{Group Identifiers}  \subsection{Group Identifiers}
156    \label{subsec:groupids}
157    
158  A \emph{group identifier} is used to uniquely and universally identify individual groups.  They are attached to proprietary resources for the purpose of referencing the group (or groups) whose members are authorized to access that resource.  When a system needs to do an authorization check because a request for access is being made, it can make the decision based on the response of a membership call to a GMS service.  With the help of an IVOA Registry, the system has all the information it needs within the group identifier to locate the associated GMS service and formulate the REST call to that service for the membership check.  A \emph{group identifier} is used to uniquely and universally identify individual groups.  They are attached to proprietary resources for the purpose of referencing the group (or groups) whose members are authorized to access that resource.  When a system needs to do an authorization check because a request for access is being made, it can make the decision based on the response of a membership call to a GMS service.  With the help of an IVOA Registry, the system has all the information it needs within the group identifier to locate the associated GMS service and formulate the REST call to that service for the membership check.
159    
# Line 246  Line 251 
251  \item{500} - A service operation failure.    \item{500} - A service operation failure.  
252  \end{itemize}  \end{itemize}
253    
 \subsection {GMS and Credential Delegation}  
   
 It is unlikely that users would need to make use of GMS directly.   unless they would like to ask the service about their group membership for informational purposes.  The main use cases involve systems and services calling GMS for authorization checks.  
   Thus, these systems and services need to make the GMS call  
 This pattern will be in use when the call is being made by a service that supports and implements the IVOA Credential Delegation Protocol \citep{2010ivoa.spec.0218P}.  
   
 TBD  
   
254  \subsection {Search Examples}  \subsection {Search Examples}
255    \label{subsec:examples}
256    
257  \paragraph{Example 1 - Group access to a VOSpace Node}  \paragraph{Example 1 - Group access to a VOSpace Node}
258    
# Line 308  Line 306 
306    
307  The TAP service caches this group membership information for the lifetime of the request so that it can be used if necessary when checking other rows.  If a read-group entry with a different \emph{registry part} of the group identifier is encountered, the TAP service must call that GMS service too and add the list of groups to its cache.  The TAP service caches this group membership information for the lifetime of the request so that it can be used if necessary when checking other rows.  If a read-group entry with a different \emph{registry part} of the group identifier is encountered, the TAP service must call that GMS service too and add the list of groups to its cache.
308    
309  \section {Implementation}  \subsection {GMS and Credential Delegation}
310    \label{subsec:creddel}
311    
312  \subsection {Implementation Options}  User and group membership information may be considered private, so determining who is allowed to make GMS search calls is an important consideration.  This is part of the reason why the specification only allows for group membership checks to be made by the user whose membership is being checked (the 'target user').  This rule ensures that only the target user can see their group membership information.
313    
314  \begin{itemize}  This rule also means that the caller of GMS must use the credentials (proxy certificate, token, etc..) of the target user.  Although users may themselves call GMS for membership information it is generally not very useful in their hands.  The target use case is for programmatic systems to call GMS for authorization checks.  So, those systems must have access to the target user's credentials.  This is accomplished through use of the IVOA Credential Delegation Protocol \citep{2010ivoa.spec.0218P}.
 \item Via Grouper (groups in MySQL, users in LDAP) \footnote{https://www.internet2.edu/products-services/trust-identity/grouper/}  
 \item LDAP only with memberOf plugin (supports groups-of-groups)  
 \item VOSpace implementation: ContainerNodes = groups, DataNodes = users  
 \end{itemize}  
315    
316  \subsection{User Identity}  An alternative to this approach, which was thoroughly considered, is to also allow the use of privileged credentials to make GMS calls.  That is: allow the set of systems that need to do authorization checks to make GMS calls for any target user.  There are a number of problems with this.
317    
318  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.  New systems that need to do authorization checks require authorization to make those calls so would have to be added to a set of rules.  This is a maintenance step that can be avoided.  When there is a chain of privileged service calls that need to be made, the complexity of mapping and maintaining those rules increases quickly.  This complexity is compounded when needing to interoperate with external GMS instances.
319    
320  (Author note: add reference or table of user identity types.)  Another problem with making external GMS calls with privileged accounts is the need for a trust arrangement between the hosts.  Organizations would need to ask each other to allow GMS calls to work for certain privileged accounts.
321    
322  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 realm.  If a user identity reaches beyond the scope of a GMS service's realm (such as an X.509 client certificate), then it, too, may be referenced by the service.  When service calls are always made by the originating user, then services such as GMS only have to concern themselves with the caller of the service, so the complexity and potential for error is much reduced.  Information privacy is easily controlled when only the user may see membership information.
323    
324    \section {Implementation}
325    
326  \subsection{Information Privacy}  \subsection {Implementation Options}
327  \label{subsec:infopriv}  \label{subsec:implopts}
328    
329  User and group membership information may be private, so determining who is allowed to make GMS search calls must be considered when implementing a GMS service.  A GMS implementation may insist that GMS search calls must be made by a certain privileged account only.  This is a reasonable approach when the service is only used with a single organization, but would require the distribution of those privileged credentials to any external sites wishing to use it.  An implementation of GMS requires a system that associates users with zero or more groups, some options include:
330    
331  Alternatively, a GMS service could have a policy where only the user who is the subject of the membership assertions is allowed to make the GMS search calls.  This approach lends itself well to external interoperability because there need not be any sharing of credentials or trust arrangements between sites -- it is always only the user who makes the service calls, even when they are transitive.  This is the approach recommended in the  IVOA credential delegation protocol \citep{2010ivoa.spec.0218P}.  So, aside from the architectural benefits of employing this pattern, there are some information privacy concerns that are addressed.  \begin{itemize}
332    \item Via Grouper (groups in MySQL, users in LDAP) \footnote{https://www.internet2.edu/products-services/trust-identity/grouper/}
333    \item By using LDAP only with group membership plugins.
334    \item Through a relational database.
335    \item A VOSpace implementation: It is conceivable that VOSpace could be used to implement GMS, where ContainerNodes represent groups and DataNodes represent users.
336    \end{itemize}
337    
338  \subsection{Groups of Groups}  \subsection{Groups of Groups}
339    \label{subsec:groupsofgroups}
340    
341  It may be functionally attractive to support groups within groups.  If this is implemented, then the service must ensure that this representation is reflected by the service API.  For example, if an isMember(g) call is made, and the group 'g' is a group within another group in which the user is a member, then the service must return true.  The fact that the service supports groups within groups is not exposed through the search API, but the API does not prohibit such an implementation.  It may be functionally attractive to support groups within groups.  If this is implemented, then the service must ensure that this representation is reflected by the service API.  For example, if an isMember(g) call is made, and the group 'g' is a group within another group in which the user is a member, then the service must return true.  The fact that the service supports groups within groups is not exposed through the search API, but the API does not prohibit such an implementation.
342    
343  If one of the contained groups actually exists at another GMS instance, perhaps outside of the organization, then the service must transitively query that service to determine group membership.  If one of the contained groups exists at another GMS instance, perhaps outside of the organization, then the service may transitively query that service to determine group membership, taking care to avoid a loop caused by groups being members of each other.
344    
345  \appendix  \appendix
346    
347  \section{Changes from Previous Versions}  \section{Changes from Previous Versions}
348    \label{sec:changehistory}
349    
350  \subsection{Changes from WD-GMS-1.0-20190506}  \subsection{Changes from WD-GMS-1.0-20190506}
351  \begin{itemize}  \begin{itemize}
352  \item{General text changes for clarification in abstract and sections 1, 3}  \item{General text changes for clarification in abstract and sections 1, 3}
353  \item{Removed support for identifying the 'target user' of a GMS call with id parameters.  The 'target user' is now always the user making the REST API call to GMS.}  \item{Removed support for identifying the 'target user' of a GMS call with id parameters.  The 'target user' is now always the user making the API call to GMS.}
354  \item{Added new sub-section: GMS and Credential Delegation}  \item{Added new sub-section: GMS and Credential Delegation}
355  \end{itemize}  \end{itemize}
356    

Legend:
Removed from v.5734  
changed lines
  Added in v.5735

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