Shibboleth Developers

["Howard Gilbert" <>]

I let this slip by a few days ago, and then out of the blue it came back to
me:

Howard:
> > It has been proposed that Security administration only really works at
> the
> > Entity level even if the Metadata defines KeyDescriptor as an element of
> > Role. So do we aggregate all the Keys at the Entity level and,
> therefore,
> > accept a Key that is configured for a different Role than the one that
> > actually presents it.

Scott:
> No, definitely not, anymore than I currently allow an AA to use a key
> named
> "foo" because there'a a HandleService element with that Name.


Walter just said that he is integrating the IdP SSO (HS) and AA Servlets
into a combined class because of requirements like Attribute push. If you
need to build a SAML Reply containing both an Authentication and an
Attribute Statement, then it is easier if they are different aspects of the
same code.

It makes sense for a lot of people to issue a single Certificate/Key to the
IdP and use it for both the SSO and AA functions. It is somewhat scholastic
to require that two statements in the same Reply be signed by different
certificates because they were issued from different roles.

Of course, one can simply put the same Certificate in two KeyInfo elements
under the two Roles in the Metadata. If we agree that the algorithm runs
Role based, I would expect that this is the way that the quickstart,
checklist, and configuration examples would work.

The other approach works in all cases of proper use. If the algorithm were
Entity based, then if a Role is configured with a Key and uses that Key its
statements validate. It is just that certain "errors" don't get caught, as
when the SSO and AA have different keys but the SSO signs both statements in
an attribute push reply. My problem is that I don't see a benefit to
catching these "errors".