Generic attributes comes as a unified solution for these three requirements

  • 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

Topic revision: r4 - 2007-02-26 - AndreaCeccanti
This site is powered by the TWiki collaboration platformCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback