Shibboleth Developers

["David L. Wasley" <>]

Title: RE: Shib and portals

Mark, I like the idea of "encrypted bundles" suitable for use by each target behind the portal but does that scale?  How do I avoid the need to have N bundles for N targets?  And what if the portal user adds a new target during a session?

So, looking ahead to where the number of tiers may go beyond 3, it seems to me there are 2 fundamental paradigms:

(1)  [User]->[Portal]--(B1+2+3+...)-->[WS1]--(B2+3+...)-->[WS2]--(B3+...)-->...

               |  ^

               | (portal attrib + bundles B1 thru Bn for all tiers)

               v  |

       [Attribute Authority]

(2)  [User]->[Portal]---------------->[WS1]-------------->[WS2]------------>...

               |  ^                    | ^                 | ^

               | (portal attrib)       |(B1)               |(B2)

               v  |                    v |                 v |

       [<-------------------Attribute Authority---------------------->]

(Sorry about the awkward diagram)

Basically, in model-1 the portal has to anticipate all the downstream web services it might need and acquire bundles for each, which are then passed along as necessary.  This is simpler in terms of interaction with the AA but more complex in terms of configuration of the portal (what bundles does it need to get?) and carrying information around.

In model-2 each WS gets what it needs directly from the source when it needs it.  If it needs additional information (another variation on Shib behavior -- going back for more if the user requests additional access rights ...) it knows how to get it.  If it wants to verify "presence" it could to that too, using the SSS paradigm.

Of course, neither model deals with the case where the "origin" that a user wishes to assert is different at each tier, but I don't thinks we want to tackle that little wrinkle right now.

So, while I agree with Mark that implementing model-1 (with encryption) initially is probably the more practical approach - it is certainly easier - I do think that we shouldn't preclude evolving to model-2 as well.

        David

PS: I realize that at least initially the number N will be quite finite.

-----

At 10:15 AM -0400 on 9/25/03, Wilcox, Mark wrote:

> I think caching has to be built into the
> model from a scalability point of view. Yes, I realize premature
> optimization is the root of all evil but look we're not in totally
> unfamiliar ground here -- we know what caching is a likely scenario at
> some point.
>  
> What I think should be considered -- is
> perhaps having sub-elements being encrypted by different
> keys.
>  
> For example to follow the charge-card
> example -- the portal could cache it if it was encrypted by a private
> key that only 'cleared' vendors had access to.
>  
> Not perfect, but more secure than common
> practice today and I think could be an acceptable
> compromise.
>  
> Mark
> > -----Original Message-----
> > From: David L. Wasley [mailto:]
> > Sent: Wed 9/24/2003 5:21 PM
> > To: ;
> > Cc:
> > Subject: Re: Shib and portals
> > Steven, I am strongly of the opinion that asking the
> > portal to cache
> > and forward attributes is a bad model for 2 significant reasons:
> >
> > 1) It violates the "minimum necessary information" model -
> > the portal
> > "knows" more that it needs to and this could result in a
> > compromise
> > of users' privacy.  Suppose we get to a point where my bank is
> > my
> > Identity Service Provider (Origin) and I want it to release my
> > charge
> > account number to vendors - should the shopping portal cache
> > (cash?)
> > that information?
> >
> > 2) Enforcement of the AA's attribute release policy must be
> > extended
> > somehow to the portal so that the user's preferences, etc., are
> > respected.  This adds unnecessary complexity.
> >
> > I believe there is a very straight forward way to deal with the
> > portal N-tier problem.  Attached is the proposal I wrote up long
> > ago
> > - I've not heard feedback that would suggest it isn't
> > workable.
> > It avoids the need for caching of attributes in the portal since
> > it
> > enables the web service to communicate directly with the AA.
> >
> >         David
> >
> > PS: I'm sorry I couldn't make the recent Shib design con call. 
> > I'll
> > be sure to join you next time.
> > -----
> > At 4:23 PM -0400 on 9/24/03,  wrote:
> >
> > >18-24 months ago, we had a quite a bit of discussion about how
> > to
> > >integrate Shib and portals (or, more specifically, uportal). At
> > that
> > >time, we stopped the discussion, because 1) the problem is hard,
> > and
> > >2) it was clear that we wouldn't be addressing this scenario
> > with
> > >the initial implementation.
> > >
> > >Now, we're begun discussions about the next version of Shib,
> > and
> > >we're once again looking at this question.
> > >
> > >So far, in conference calls, we've managed to revisit and tour
> > much
> > >of the same landscape we explored all those many months  ago.
> > One of
> > >the popular discussion items is the basic model -- we go round
> > and
> > >round on whether the portal can cache credentials and attributes 
> > or
> > >not. Should the portal obtain and hold a superset of all the
> > >attributes required by the various channels it contains, and
> > pass
> > >these attributes on to the channels, or  should each channel
> > that
> > >needs shib attributes make a separate request back  to the
> > AA?
> > >
> > >So far, there's been no obvious answer. One recent
> > breakthrough,
> > >tho, has been to look at this from the trust perspective. And to
> > ask
> > >"are there channels (applications) that would  not trust
> > the proxy
> > >to obtain and forward attributes on their behalf?". We can
> > imagine
> > >that there *might be* intra-domain applications with this
> > >constraint; its easier to  imagine inter-domain applications
> > with
> > >this constraint. But, while we can imagine these situations, we
> > also
> > >see that virtually all current portal deploys do cache
> > credentials,
> > >and this seems to be  quite  acceptable to campuses. We
> > certainly
> > >don't hear lots of screams about this.
> > >
> > >And, so far, we don't have a concrete use case in front  of
> > us where
> > >the channel  WILL NOT use forwarded attributes......
> > >
> > >Can someone think of one?
> > >