Shibboleth Developers

[Brent Putman <>]

Tom Scavo wrote:

> Chad's proposal is based on WS-*, and as you probably know,
> transport-level security is still the default in GT4.  Message-level
> security, although it's included in GT4, will remain mostly a research
> topic until the standards have solidified and the performance issues
> have been addressed.
>
> One of our requirements is that GridShib MUST work with pre-WS GT4
> deployments (which is most of them), which means we don't have the
> luxury of SAML 2.0 and WS-*, at least for this first iteration of the
> technology.  So our use case is considerably more constrained than
> yours.
>  

Well, yes, I understand your requirement for transport-level security 
(via Globus GSI, grid certificicates), but I don't see how this 
precludes that.  The way that I understand it, the GT-4 interactions in 
this proposal would all still be transport-level security, meaning that 
by the time the GridShib client user submits the request to the Grid 
service they have a cert, and are using the standard Globus GSI 
transport layer mechanisms.  It is essentially like the existing MyProxy 
model: something MyProxy-like is the security token service (STS), is 
SAML and WS-* aware, and able to issue certs based on SAML assertions as 
the credential type. 

I wasn't actually suggesting the entire flow in Chad's model, (such as 
the ability of a Grid service to renew a proxy cert via a request to the 
STS), just the initial mechanism of conversion of a credential issued by 
an IdP into a Grid certificate by means of a SAML-aware STS (e.g. 
enhanced MyProxy).  Only the GridShib client would need to be SAML and 
WS-* aware - is that a problem?

Am I missing something?

Thanks,
Brent