Skip to Content.
Sympa Menu

shibboleth-dev - RE: attribute push

Subject: Shibboleth Developers

List archive

RE: attribute push


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: attribute push
  • Date: Mon, 11 Sep 2006 14:01:53 -0400
  • Organization: The Ohio State University

> Isn't the entire authn response exposed in the case of attribute push?
> In that case, there are two assertions, right?

There can be, it depends what the IdP does. But yes, you're right. That was
a consequence of the design, but it wasn't the *intent*. The goal has never
been (in the past) to expose the SAML for, say, forwarding. It was strictly
for consumption of XML-valued attributes.

So these are different goals and probably means rethinking the approach.

> Yeah, I guess it's a new feature. The idea, of course, is to expose
> the authentication context for the purposes of access control. How
> exactly that happens is less important.

That isn't *my* goal, per se, it's to support ID-WSF, which requires getting
at the bootstrap EPR in an attribute, and possibly having to use the
original assertion as a security token. Either way, the whole thing has to
be there, and it cannot be modified in any way. That also means no
filtering, of course, which is a problem for other use cases.

It's quite hard, and the configuration of it all will become more complex
and confusing. And it probably will be very difficult for non-Java
applications to use, involving loopback requests into the server of some
sort to get around the header problems.

There's no need to play games like this in something like GridShib, if
you're getting the information through some other mechanism.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page