Shibboleth Developers

[Sean Mehan <>]

Dear Shibbers,

I see that there are some interesting posts just now, so please allow 
me to dive in.

The Guanxi project (www.guanxi.uhi.ac.uk) has been thinking hard about
the need to establish registries for attributes. There has been some 
thinking about
ADP - Attribute Demand Policies on the UK side of the pond. This would 
be exposed as a WS
and whose address is sent to an IdP as part of a SAML attribute 
request. This is presently
not supported by SAML, but at least a couple of people  over here 
thought it was a good idea.

Guanxi has a Java IdP Shib implementation and a Java SAML toolkit, and 
is currently building a Java SP implementation.
And some of our thinking has been about supporting ADDI.

ADDI - Attribute Description & Discovery Interface

Shibboleth expects an IdP to release all attributes if none have been 
requested
using SAML AttributeDesignator elements in a SAML AttributeRequest. If 
no
AttributeDesignators are present, the whole lot gets sent out subject to
the ARP.

Proposal:

1) ADDI registry at an SP has resource specific attribute sets. i.e. an
IdP queries the SP's ADDI to find out what attributes are required to
access a specific resource.

2) ADDI registry also holds vendor specific mappings. These would be URN
identified for common discovery, e.g. urn:novell:nds

This would in effect be WSDL for AAAA, i.e., an IdP would find out what
attributes are required to access the service and also how to map them 
to
it's own local set, all provided by the SP's ADDI service.

This now leads to a new SAML profile, in the first instance just 
extending
shibboleth's Browser/POST:

1) User accesses resource at SP
2) SP sends GET request to user's IdP after WAYF finds out where that 
is.
3) IdP authenticates user and sends AuthenticationStatement back to SP.
4) SP sends AttributeRequest to SP
5) NEW - IdP queries SP's ADDI service for required attributes and any
vendor specific mappings based on the resource the user wants to access.
6) IdP maps required attributes to local set and releases them based on 
ARP
7) SP makes decision based on incoming attributes from the IdP.

So, there's only one modified step (5) - the IdP queries the SP's ADDI
service, rather than relying on the presence/absence of
AttributeDesignator in the AttributeRequest. In this case the
AttributeRequest would contain the address of the SP's ADDI service.

This is an addition to SAML, but we have an SAML toolkit, called
SAMUEL (SAMl Used in ELearning) that could take this on board.

So, Guanxi could provide 3 things:
1) An IdP-side ADDI call instead of AttributeDesignator parsing
2) An SP-side ADDI service
3) Extended SAML AttributeRequest to publish the address of the ADDI
service. This would be done with SAMUEL, if nothing else.

If a normal AttributeRequest from a standard shibb SP came in, Guanxi
would just switch to normal shibb mode and forget about ADDI.

Regards,
Sean Mehan
Guanxi Project Manager

On 27 Apr 2005, at 14:57, Alistair Young wrote:

> > Is Guanxi a deployment of Shibboleth or an implementation of
> > Shibboleth?  (An implementation would be reinventing the wheel.)
> It's an implementation of the Shibboleth profile. It's not reinventing 
> the wheel as we plan to add other things to it, other than Shibboleth 
> support, such as SAML support for web services. Anyway, it's always 
> healthy to have more than one implementation of things.
>
> > SAMUEL ... Can you give a reference?
> http://sourceforge.net/projects/guanxi/
> it's part of the Guanxi project - it differs from openSAML in 
> implementation. We want SAML2 support as well as extensions. For 
> example, we're looking at ADDI, sort of WSDL for service providers, 
> where an IdP can query an SP to see what attributes it requires to 
> release for a resource. We can explore that using SAMUEL.
>
> > > http://bodington.org/
> > > http://sourceforge.net/projects/bodington
> >
> > More deployments?
> deployments of Guanxi.
>
> The Guanxi IdP differs from the shibb one in that it can be used 
> without any configuration when run inside Bodington. It provides a low 
> cost entry for people into the shibboleth/saml world. For info on the 
> embedded IdP see:
> http://www.weblogs.uhi.ac.uk/sm00ay/?p=71
>
> Alistair
>
>
>
> On 27 Apr 2005, at 14:44, Tom Scavo wrote:
>
> > On 4/27/05, Alistair Young 
> > <>
> >  wrote:
> > > Do you mean all the SAML1.1 browser profiles Tom? Browser/POST,
> > > Artifact etc?
> >
> > Yes, both Browser/POST and Browser/Artifact (so only Shib 1.3 
> > qualifies).
> >
> > > Is it likely that a single application would support all possible 
> > > SAML
> > > profiles?
> >
> > There are only two SAML 1.1 profiles (above), so the requirements are
> > not too steep.  Of course SAML2 is another question altogether.
> >
> > > The JISC funded Guanxi project:
> > > http://www.jisc.ac.uk/index.cfm?name=project_guanxi
> > > http://www.guanxi.uhi.ac.uk
> > > http://sourceforge.net/projects/guanxi/
> > >
> > > is an open source implementation of the SAML1.1 Shibboleth profile,
> > > i.e. it's a Shibboleth compatible IdP and SP.
> >
> > Is Guanxi a deployment of Shibboleth or an implementation of
> > Shibboleth?  (An implementation would be reinventing the wheel.)
> >
> > > SAMUEL (SAMl Used in E Learning) is an open source partial
> > > imlementation of the SAML1.1 spec. It's a toolkit for building SAML
> > > packets. It's part of the Guanxi project.
> >
> > Can you give a reference?  How does SAMUEL differ from OpenSAML?
> >
> > > Currently Guanxi is an IdP with the SP part due out in the next few
> > > months.
> > >
> > > The open source Bodington VLE has an embedded Guanxi IdP, giving it
> > > Shibboleth compatibility out of the box:
> > > http://bodington.org/
> > > http://sourceforge.net/projects/bodington
> >
> > More deployments?
> >
> > Thanks for the pointers, Alistair.  I appreciate it.
> >
> > Tom