Skip to Content.
Sympa Menu

shibboleth-dev - RE: GridShib integration

Subject: Shibboleth Developers

List archive

RE: GridShib integration


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>
  • Cc: "'Shibboleth Development'" <>
  • Subject: RE: GridShib integration
  • Date: Wed, 2 Mar 2005 23:48:07 -0500
  • Organization: The Ohio State University

> That's a possibility. If someone is already doing this, we'd love to
> hear about it.

The UT system and Wisconsin come to mind.

> We're not so much interested in the session (since a grid service
> maintains its own) as we are in the resulting attributes. We've
> developed a profile along these lines but it requires us to generate
> an authn assertion to tap into the ACS, which we'd like to avoid.

I know, and Booz-Allen just submitted essentially the same profile to the
SSTC, plus some extra encryption and other weirdness.

> I don't totally understand the comment. No, we don't need an ACS
> since we don't necessarily have an authn assertion to consume, but how
> else do we get attributes short of implementing an AR ourselves?

It sounded like what you were saying was, you go to the "ACS" with a client
cert, instead of an assertion, and then that would be like a substitute for
an assertion containing the subject from the certificate. That would be
relatively simple to do, assuming you're willing to let the module build a
session, because that's all the code knows how to do.

But my point was, you don't really need a special location, if you just
require SSL across the whole site. Then the session is just the
authenticated client, and the cache can key off of that and fetch/maintain
the attributes for it.

That seemed reasonable to me because if you're not going to use SSL across
the site, you're losing virtually every bit of security, and why do that if
you went through the unbelievable agony of dealing with client certs in the
first place?

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page