Skip to Content.
Sympa Menu

shibboleth-dev - RE: Possible to proxy attribute assertions?

Subject: Shibboleth Developers

List archive

RE: Possible to proxy attribute assertions?


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Peter Murray'" <>, <>
  • Subject: RE: Possible to proxy attribute assertions?
  • Date: Sun, 20 Mar 2005 14:52:42 -0500
  • Organization: The Ohio State University

> One very inelegant option that occurred to me is to have the MSE act as
> an IdP in an exchange with the destination SP. In such a role, the
> attribute assertions would "pass through" the MSE from the
> original IdP.

Mark's note about privacy was very important, but you also haven't
identified the protocol here. I seriously doubt that it's HTTP alone, that
wouldn't make a great deal of sense. I assume it's SOAP. That makes this a
web service, and there is nothing in the SAML browser profiles that
addresses web services.

> Assuming a SP supports Shibboleth and all other things being equal
> (federation memberships, etc.), what I'm trying to work out is if it is
> possible to leverage the same access control infrastructure that a
> client would use to directly access a SP to also control a client's
> requests coming through a MSE. After working this through, it seems
> like the answer is 'no' -- which comes as a shock because my first
> impressions were more along the lines of 'no problem.'

Shibboleth implementation security contexts are cookies. Everything else is
just "get data associated with the cookie". Delivery of assertions is
governed by the browser profiles (or a back channel that is really not
separable from them). Without a browser, you need a new profile for session
context establishment.

So it's really simple...if you're not using cookies or something similar as
the resulting security context, the outer implementation is just not
directly applicable. Shibboleth doesn't do access control itself. The
implementation provides for it in a very rudimentary way as an addendum to
the HTTP-specific behavior of the implementation, but it's more common that
the application is responsible for access control.

The issue isn't access control so much as session establishment. SOAP
doesn't have sessions without other specs. You could use cookies with it,
but that's not so common because it creates a dependency on HTTP, which is
normally fine except the SOAP guys hate to give up that fiction of transport
independence. In practice, that's a joke, of course.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page