 |
 |
On 5/9/06, Mark Norman <[log in to unmask]> wrote: > > For anyone that is interested in this kind of thing, and the management > of policies in particular, we have a document on our wiki (for the > ESP-GRID project at) > http://wiki.oucs.ox.ac.uk/esp-grid/PolicyManagementAndExchange > > It may be a little grid-oriented for some, but any thoughts and feedback > would be very welcome! Mark, I'm not sure if you wanted feedback posted here but please find some comments below. Hope this helps. > Shibboleth is well placed to provide an infrastructure in which to > manage and deliver attributes needed by access policies to make > authorisation decisions. Efforts are now appearing to provide > software and interfaces with which to manage those attributes. For > example, the [WWW] MAMS initiative has developed a tool known as > [WWW] ShARPE (Shibboleth Attribute Request Policy Editor) in which > the local institution is able to set any local policies that will > affect its users' access to external (and presumably, internal) > resources. Yes, I saw ShARPE demoed at the Internet2 Member Meeting last month. Impressive. Now if only it were packaged as a Shib 1.3 extension... > A similar initiative, and one which has fed into ShARPE no > doubt, has been pursued at Internet2 and is called [WWW] SIGNET. I don't see any clear relationship between ShARPE and Signet. The latter (a privilege management system) is totally separate from Shibboleth. > One particular item to note regarding ShARPE, is > that this initiative has suggested the use of an XML Service > Description file. This file effectively conveys something about the > authorisation policy of the SP, and the user attributes required for > granting access to each "service level" provided by the SP are given > in this file. The file is public and held (and advertised) at the > federation level. This model is prevalent today, yes. I wonder if ShARPE will help usher in an alternative model, one that focuses on the SP as the producer of metadata. After all, this is where the access policy resides. > We should also note that the [WWW] SWITCHaai initiative in > Switzerland also has a system of managing the 'advertising' of the > SP's authorisation policy (or at least the required attributes) at > the federation level. SWITCH calls this its Resource Registry and > this is already in production for the Higher Education users in > Switzerland. The list of resources and this meta-data is published at > the federation level within the federation metadata file. However, > SWITCH predicts that keeping all of this information in the one file > will eventually lead to scalability problems and may move to > publishing such information in many files. Exactly. SWITCH is a relatively small federation and already it sees the handwriting on the wall. Seems a different model for producing and distributing metadata is needed, one that encourages IdPs and SPs to call out attribute availability and requirements, respectively. > In these initiatives it is possible to impose local institutions' (or > communities') access policies upon sets of users. However, > additionally, the user can impose his own privacy requirements on the > exchanges. For example, the user may not wish to reveal certain > attributes about himself and this could restrict his access to > certain sites (as those sites mandate the presentation of those > attributes). An example of this functionality is the 'Autograph' > interface being developed in parallel with the [WWW] ShARPE tool > where the user can edit and manage the release policies in this way. Autograph is an important piece of the puzzle, but wouldn't it be great if a user request for a protected resource at the SP resulted in a corresponding user ARP at the IdP? Then Autograph could be used to manipulate the ARPs out-of-band. > There are potentially many ways in which the technologies provided- > for and enabled by Shibboleth and those associated with grids could > be combined. Probably the most advanced implementation to combine > elements of Shibboleth with elements of grid access management is to > be found within the [WWW] GridShib project. GridShib is an > integration of the [WWW] Globus Toolkit and Shibboleth. The complete > software package consists of two plugins, one for Globus Toolkit (to > use SAML to discover the attributes) and another for Shibboleth (to > provide the attributes to the grid SP). With both plugins installed > and configured, a GT Grid Service Provider (SP) may securely request > user attributes from a Shibboleth Identity Provider. There are two > main GridShib scenarios: one involving the 'push' of authorisation- > enabling attributes, and another of the 'pull' of those attributes. Yes, but currently only a "pull" profile has been implemented. A clear use case for "push" has yet to be identified. > 2.3.2. Shibboleth should help with VOs > > One area where Shibboleth should be able to provide a good workable > solution to grid applications is with VOs. This was one of the > drivers of the GridShib project. The GridShib project saw that the VO > could be represented by another Shibboleth attribute authority (AA). This vision manifests itself in the recent (and ongoing) myVocs-GridShib integration effort: http://grid.ncsa.uiuc.edu/presentations/i2mm-myvocs-gridshib-april06.ppt Briefly, myVocs inserts a layer of Shib-based middleware between the SP and the IdP. Thus myVocs serves as a source of VO attributes (in addition to the federation attributes obtained from the IdP). > 3.2. VOs and Shibboleth > > One one level, the management of VOs, as lists of users with possible > other attributes, would seem to be perfectly suited to the general > Shibboleth model. However, the problem exists that the current > version of Shibboleth (v 1.3) as well as the upcoming versions (2.0 > and probably 2.1) consider the AA to be owned by the IdP (home > organisation). If the Shibboleth mechanism allowed multiple AAs to be > queried then this would enable independent and ad hoc VOs to be > created and maintained. This is precisely what myVocs does. See https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/MyVocs for some background material on myVocs. > As noted above, the GridShib project considered the Shibboleth AA to > be an attractive point from which to query attributes regarding > users. However, the project is currently restricted in that the home > organisation is expected to maintain the VO list of users. No, it's unreasonable to assume the home site will ever be convinced to maintain VO attributes. That's why we've teamed up with myVocs. > Note that the assertion of attributes between a Shibboleth AA > and a VOMS server has been carried out by the GridShib project > as a proof of concept. To my knowledge, this has not been done. > The developers of the ShARPE tool chose to publish the authorisation > policies of the service providers (SPs) in XML files then held at the > Shibboleth federation level. This is described within the main > ''Shibboleth'' section above and should assist sites in supporting > their users and also service providers in having transparent access > management policies. The creation of these XML files by the SPs > should, in theory, be able to be carried out by the PERMIS tools. To clarify, the XML files are extended SAML 2.0 metadata files. AFAIK, no tools exist to produce these files, and I don't see how PERMIS can help in this regard. Tom