3.3 Resource sharing: trust and security  (Page 3/4)

Key to this model is trust and security. Sites need to be sure that collaborating sites have adopted appropriate security policies for authentication for example and that they have appropriate rigor in management of strength of user passwords and ideally, support a unified institutional account management. It is also the case that for some virtual organizations, some sites may be recognized (trusted) whilst others may not. A given SP might only be available to members of a particular virtual organization for example, and only researchers at the sites involved in the collaboration should be able to access and use the SP resources. Similarly, given institutions need to be able to define which attributes they wish to send to which SPs. A naïve model would be that all attributes for a given user from a given site would be sent through to a given SP. However an improved model would support a targeted (reduced) subset of attributes that are released based upon what that service requires to make an access control decision. The Open Middleware Infrastructure Initiative (OMII-UK) funded the Security Portlets simplifying Access and Management of Grid Portals project (SPAM-GP), which developed tools that support precisely such requirements.

Scoping of trust and protecting of resources: finer grained security of portals

Figure 1 illustrates how a given Grid portal can be accessed through Shibboleth. However, it is essential for many domains that access to such resources is restricted further. Simply knowing that someone has authenticated at the University of Glasgow will typically not be sufficient for access control to clinical data sets that might be available through the portal for example. To support this finer-grained scoping of trust and associated authorisation, the SPAM-GP project implemented a variety of JSR168 compliant portlets that a portal administrator could apply to support finer-grained security of their portals and the portal content, e.g. portlets that give access to remote VO-specific resources, in a Shibboleth-environment.

The first such portlet developed was the SCAMP (Scoped Attribute Management Portlet). This portlet allows restricted and syntactically correct manipulation of the Attribute Acceptance Policy (AAP) of a Shibboleth SP to streamline the subset of IdPs from whom a portal will accept user attributes. Thus if a collaboration only involves a subset of organizations in the UK federation, then SCAMP allows to limit access to the portal to that subset of sites. To achieve this, the portlet parses the federation metadata for the list of all the IdPs within the federation, and stores the values of the ‘scope’ entry for each IdP.

When the SP is provided with a scoped attribute, the suffix will by definition be one of these scoped values. The list of IdP scopes in the federation is provided to the user/portal administrator in the form of a drop down list, one per user attribute, where the institutions from whom attributes are to be recognized/accepted from may be selected. The first time the portlet runs, the policy will set all attributes to ‘scoped’ but with no scope defined, so the default behaviour will be to accept attributes from no institutions – a default common with most security infrastructures, i.e. deny all. Subsequently collaborating sites can be iteratively added to build a VO at the attribute level by the portal manager. Once defined, these changes can then be added to the AAP file. This policy information will then subsequently be available for the next browser session referencing that resource, i.e. only allowing access to the resources from known and trusted sites with expected attributes.