Skip to Content.
Sympa Menu

shibboleth-dev - Re: [Shib-Dev] protocols and profiles

Subject: Shibboleth Developers

List archive

Re: [Shib-Dev] protocols and profiles


Chronological Thread 
  • From: Peter Williams <>
  • To: "" <>
  • Cc: "" <>
  • Subject: Re: [Shib-Dev] protocols and profiles
  • Date: Tue, 27 Oct 2009 17:52:20 -0700
  • Accept-language: en-US
  • Acceptlanguage: en-US

If anyone is interested, we did some attribute aggregation, but under
"saml controls". It's somewhat of a special case, but perhaps a useful
example.

In our world, there are two classes of sp: those in some class doing
account linking and provisioning an sp side name for a pseuodonym
format nameid, and a second class of other sp entities which are in a
formal saml sp affiliation relationship with some sp of the first class.

The primary sp in the affiliation can act as an attribute authority to
the secondary SPs in the affiliation, in which per user "attributes"
maintained by the primary sp are merged with those from the idp ( when
sent to a secondary sp in an assertion or query response, as normal ).

In general, the attributes sourced from the primary sp are provisioned
by that sp ( rather than being copies of values originated by the idp
itself). The example is risk score. When normal saml flows between idp
and primary sp occur, neural network risk scoring is performed by that
sp upon data associated with the act of a browser posting the (opaque,
possibly encrypted) assertion. This risk management value (read
reputation value in web2.0 speak) is then shared with other sp in the
affiliation (only) via the aggregation process (so their neural models
benefit from analysis performed in the more trafficked site). The sp
affiliation acts as the control regime, limiting who can access and
presumably then leverage these sp-sourced "attributes".

It's not implemented using shib, but it's the same implementation
model (a plugin to the sp handlers, which does aggregation of AA
attributes, in a manner unseen by the target webapp).

We have not yet used this for mandatory attributes. Ie the webapp may
get just the idp-sourced attribute, given system and comms failures.
IT's upto the risk module serving the sp (per app in our concept) to
decide how this impacts the principal's local reputation. This feeds
into local access controls.

On Oct 27, 2009, at 5:22 PM, "Tom Scavo"
<>
wrote:

> On Tue, Oct 27, 2009 at 7:15 PM, Scott Cantor
> <>
> wrote:
>>
>> https://spaces.internet2.edu/display/SHIB2/NativeSPAttributeResolver
>
> I must be missing something then, since I heard you remark at the
> Internet2 Member Meeting in San Antonio that there was no
> documentation (as of yet). Are we talking about two different things?
>
> Thanks,
> Tom



Archive powered by MHonArc 2.6.16.

Top of Page