Grid Security - Grid Computing: Infrastructure, Service, and Applications - page 313

We note that in static delegation, the roles at the remote institution
would need to be handwritten into the policy at the home institution.
Dynamic delegation factors shift the role-assigning powers to subordi-
nate authorities, which may delegate the ability to assign local roles to
remote attribute authorities, and vice versa. Thus a Glasgow “student”
role may be assigned to an Edinburgh computing science user, so they
may access the Glasgow resource without the Glasgow SoA knowing
about any Edinburgh roles. This trust relationship is agreed beforehand,
where it is implicit that the role of “student” at Glasgow and “trainee,” say
at Edinburgh, are equivalent. Complex delegation allows new intermedi-
ate roles with less privilege than their superior role to be dei ned and
assigned to remote attribute authorities. The DyVOSE Delegation Issuing
Service supported such dynamic creation and recognition of attribute cer-
tii cates and is described in detail in [20].
One of the key issues that has still to be resolved with attributes for the
grid community is related to the attribute release policy. At present, an SP
will request the attributes associated with the potentially opaque identi-
i er (handle) that is returned from an IdP. If a user from the University of
Glasgow is involved in numerous grid projects and VOs, and all of this
information on what VOs this person is involved in, and what their role is
in that VO, and so on are encoded in the core set of attributes, then it is
difi cult to restrict the information being released. Thus an SP may receive
more information than they might actually need to make an authorization
decision; for example, if this SP was just one of the many VOs that the user
was involved in, then this SP would know more about all VOs the user
was involved in. Of course, these attributes will be encoded; however, the
SP will be able to decode the attributes due to the trust relationships and
certii cates previously put in place. It is possible to have a richer array of
attributes other than the core set of eduPerson attributes, but for inter-
operability and simplicity having a core set is benei cial. Given that the
focus of much of the grid community as being represented by the NGS
does not focus upon privacy or coni dentiality, such issues are not imme-
diately important. Once more security-focused groups are involved; how-
ever, attribute release policies will become more important and only those
attributes absolutely needed will be released.
To support the dei nition and enforcement of attribute release and
acceptance policies, the Open Middleware Infrastructure Institute (OMII)
Security Portlets simplifying Access to and Management of Grid Portals
(SPAM-GP) project [21] is developing tools (portlets) that support attribute
release and attribute acceptance policies, as well as portlets that support
the coni guration of content within portals appropriate with the attributes
it receives from different IdPs. Initial results in applying these portlets
across a range of VOs are described in [22].
Alternative models, for example, based upon agreeing upon a central-
ized attribute authority (e.g., VOMS) for a specii c VO and using VOMS