Re: Seamlessness of Delegation (UNCLASSIFIED)
Paul,
Let me rephrase your use case: a Resource Broker (buybooks.com) and a
Customer establishes a business relationship where the Broker is to
find and make available a Resource (book) from some Resource Provider
(publisher/store) subject to some QoS constraints (buy book before
Thursday).
The Resource Provider(s) and Resource Broker may not have any trust
relationship established, while the Customer do, e.g. via a third
party such as a credit card company. Therefore, the Customer empowers
the Broker to act in his/her name by handing the Broker the necessary
credential information (cash withdrawal allowance or credit card
number) and then goes offline.
In the above, substitute
Resource Broker = workload manager / metascheduler
Resource = CPU time
Resource Providers = Computational Grid / Clusters
Customer = Scientific user
Credential information = URL to a MyProxy server
and you have something that is already deployed at a large scale and
used on a 24x7 basis.
Two things to note:
1. The trust relationships are Customer->Broker and Customer<-
>Provider, possibly via (different!) third party indirections.
2. There is some confusion around the much overloaded term
"delegation". The end effect of what we do here is really
impersonation as the Broker acts on the Customer's behalf in the
Customer's name - the Provider can't tell the difference (modulo
possible audit trail information tucked into the credential by the
third party/MyProxy). To be more precise, in our case the act of
delegation is really happening in the interaction between the user
and MyProxy, when the user dictates the conditions under which the
Broker can fetch a credential derived from the user.
As discussed in other threads on this list, this scenario can be
driven using attribute and identity assertions instead for many of
the use cases, though it becomes a little bit tricker when there are
no firm relationships between the Broker and Provider. For such use
cases, it's a lot easier to go the impersonation route. The trade-off
is the level of trust that the Customer must put on the Broker.
/Olle
On Apr 12, 2007, at 18:04, Friedrichs, Paul D CTR DISA PEO-IAN wrote:
Classification: UNCLASSIFIED
Caveats: NONE
Another thought...
At the moment, I am less interested in mobile users or in large batch
jobs performed by supercomputers. I'm mostly trying to address the
non-technical user's query-response where intermediaries may need
to be
involved. I need to assume the various entities are part of a governed
community but are nevertheless (or are owned by) diverse, independent
stakeholders. Human users are used to the "single sign-on"
experience. I
understand that a proxy credential can enable a single sign-on
situation
for the user, but the user may wish to use several different proxies,
and would expect (demand, actually) the authorization of these several
proxies to be as seamless as possible. I completely agree that there
should be an unambiguous ceremony associated with the business act of
authorizing the proxy, but everything else should be invisible.
I'm not suggesting that proxy credentials are necessary for the
following scenario, but it is easy for me to use to describe what I'm
striving for: After clicking on a particular button on buybooks.com, I
should see, "Are you sure you want to authorize buybooks.com to
purchase
the book 'Into Thin Air,' by John D, Smith on your behalf at a
price no
higher than 13$US no later than 12 EST 3 May 2007?" When I click "OK,"
the user's experience should be complete. But under the hood, as I
understand things, my client would put a proxy credential to a MyProxy
server and inform buybooks.com, and buybooks.com would get the proxy
credential and start looking for me. Aside from the specificity of the
delegation, I understand that this level of automation, if it does not
already exist, can be added above what may be the current
client/libraries. I'm wondering whether this is the sort of thing the
MyProxy community has been considering - essentially supporting
non-technical users.
Thanks again,
Paul
Classification: UNCLASSIFIED
Caveats: NONE