Tom Scavo wrote:
> 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.
Tom,
Thanks hugely for this useful feedback. I've sent this reply to the
list (as I think that there's some news here), but I suppose we should
take it off-list if we go much further.
<snip>
>
>> 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.
It's there because I thought that it should be mentioned in this
context. Erik Vullings (for ShARPE) pretty much said that there was no
real relationship. However, the two 'tools' overlap a little
conceptually, i.e.
"The benefits of this service include:
* a standard user interface for privilege administrators;
* consistent, simplified policy definition, via roles and
integration with core campus organizational data; ..."
But having said that, I know almost nothing about SIGNET other than what
appears on their web site.
>
>> 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.
Yes, hopefully that is the future. The current initiatives may
gradually encourage that.
>
<snip>
>> 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.
I think you mean that the first visit to the SP triggers an Autograph
session and the user gets to choose her ARP/privacy settings?
Yes - it seems an obvious next step to the functionality - I hope that
we could see this in the future.
>
>> 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.
Ah right - I think I was reading old doc.s. I'll comment on this on the
wiki.
>
>> 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).
Fantastic. I hadn't picked this up anywhere (apologies for that). I
need to get it into our document. (Nice to know that your ideas of
'What are VOs' are similar to ours! :-) )
(In grid speak) the different ways to approach VOs is as CAS does (a
central point for the authZ decision-making for all the
services/machines/SPs) or like VOMS (something providing attributes for
SPs to make their own authZ decisions). You've kind of (very
intelligently) combined these two approaches in an architecture that
will work well with Shib. And the SPs still make the AuthZ decision
(something that a lot of people seem to forget will be important).
>
>> 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.
Thanks for that - very useful.
>
>> 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.
With all this in mind, I've changed my text to:
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 was restricted in that it seemed unreasonable to
expect the home organisation to maintain the VO list of users. For this
reason, the GridShib project, teamed up with [www] myVocs (see also a
useful Powerpoint presentation at LINK.ppt). myVocs is a virtual
organization collaboration system which presents itself as a Shibboleth
SP so that other services can rely on it to ensure that the user has
been authenticated and the myVocs servers assert the attributes that the
SPs in the VO need to make their authorisation decisions."
I haven't got the space to describe it in much more detail - but I hope
that reflects reality!?!
>
>> 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.
Ah, now someone told me you had! And I just wrote it down! I'll change
that.
>
>> 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.
Ah, my mistake again, probably. I'll check on this with the PERMIS folks.
Thanks again, Tom, for the great feedback. Hope to catch you at GGF in
September?
Mark
--
Mark Norman
RTS Middleware Projects
Oxford University Computing Services
Tel. 01865 273287
http://wiki.oucs.ox.ac.uk/esp-grid/
http://www.dcoce.ox.ac.uk
