Difference: GenericAttributesReqs (1 vs. 2)

Revision 22006-12-12 - AndreaCeccanti

Line: 1 to 1
 
META TOPICPARENT name="VomsVomrsRequirements"
Changed:
<
<
Generic attributes come be as a unified solution for these three requirements
>
>
Generic attributes comes as a unified solution for these three requirements
 
Changed:
<
<
  • LHCB requirement:
>
>
  • LHCB requirement:
  LHCB needed, for usage with storage software, to associate a unique ID to each registered user. Having each piece of software calculate it independently meant risking inconsistencies, plus using very strange, non-intuitive IDs that would make service administration an extremely difficult job (to which user did ID gh37jf891j belongs?) As such, it would have made much more sense to have the ID associated to the user, hence its presence in the AC. Now that this is possible, LHCb chooses to use the user's AFS account as ID. As such, the value of these should be provided by the user themselves.
Changed:
<
<
  • LHR requirement:
>
>
  • LHR requirement:
  In the DGAS accounting system there is more than just one server on which the user's informations may end up. However, user's informations cannot be split among multiple servers. This means that each user should be associated to only a single server, and the user himself should not be allowed to change it. It then becomes natural to put the association in the user's proxy, with the HLRServer attribute. By this definition, it is clear that that the value of this attribute can only be chosen by the VOMS administrator.
Changed:
<
<
  • Shibboleth requirement:
>
>
  • Shibboleth requirement:
  To achieve full interoperability between shibboleth and voms, one of the things needed is the ability to get some of the attributes defined by a shibboleth IdP and insert them in voms proxies. It is clear that such attributes do not fall in the group/role paradigm, and so generic attributes are needed. This attributes should only be filled by the administrator (possibly with some autometed service to automatically mirror changes in the IdP).
Added:
>
>
  -- VincenzoCiaschini - 12 Dec 2006 \ No newline at end of file

Revision 12006-12-12 - VincenzoCiaschini

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="VomsVomrsRequirements"
Generic attributes come be as a unified solution for these three requirements

  • LHCB requirement: LHCB needed, for usage with storage software, to associate a unique ID to each registered user. Having each piece of software calculate it independently meant risking inconsistencies, plus using very strange, non-intuitive IDs that would make service administration an extremely difficult job (to which user did ID gh37jf891j belongs?) As such, it would have made much more sense to have the ID associated to the user, hence its presence in the AC. Now that this is possible, LHCb chooses to use the user's AFS account as ID. As such, the value of these should be provided by the user themselves.

  • LHR requirement: In the DGAS accounting system there is more than just one server on which the user's informations may end up. However, user's informations cannot be split among multiple servers. This means that each user should be associated to only a single server, and the user himself should not be allowed to change it. It then becomes natural to put the association in the user's proxy, with the HLRServer attribute. By this definition, it is clear that that the value of this attribute can only be chosen by the VOMS administrator.

  • Shibboleth requirement: To achieve full interoperability between shibboleth and voms, one of the things needed is the ability to get some of the attributes defined by a shibboleth IdP and insert them in voms proxies. It is clear that such attributes do not fall in the group/role paradigm, and so generic attributes are needed. This attributes should only be filled by the administrator (possibly with some autometed service to automatically mirror changes in the IdP).

-- VincenzoCiaschini - 12 Dec 2006

 
TWIKI.NET
This site is powered by the TWiki collaboration platformCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback