|
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?
>
|
