Skip to Content.
Sympa Menu

mace-opensaml-users - RE: is there an implementation of FilesystemCredentialResolver ?

Subject: OpenSAML user discussion

List archive

RE: is there an implementation of FilesystemCredentialResolver ?


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: is there an implementation of FilesystemCredentialResolver ?
  • Date: Mon, 11 Feb 2008 10:49:36 -0500
  • Organization: The Ohio State University

> I see. The problem is that I'm afraid the institutions I'm dealing
> with don't apply the whole standard to all its extent.

Don't confuse the need for metadata with somebody's willingness to provide
it.

> assertion). They're sending assertions signed by a certificate from a
> trusted CA, but not every institution certified by that CA should be
> allowed (just one issuer now, some but not all later).

That's why you need metadata; PKI does not address the same set of issues.

> Furthermore, the signing certificate's subject does not usefully
> identify the issuer so as to distinguish trusted from untrusted
> certificate holders.

That is, again, what metadata does.

> Therefore we're forced to just compare the
> signing certificate in the SAML assertion to the one configured for
> the issuer. This is of course less maintainable than what a normal use
> of a PKI should offer, but we don't seem able to change it.

It's not less maintainable unless you actually do revocation checking in
your PKI. Most people don't, so they gain maintainability in return for the
real security of the PKI.

> We were thinking of setting up a directory of issuer certificates,
> with the filename being the issuer's entityID (which we can't obtain
> from the signature, but we can get it from one of the signed SAML
> attributes and a DB query). This way at least the maintenance overload
> is kept to a minimun.

You get Issuer in every assertion, you don't have to query a database for
it.

> If I set up a SAML metadata file with the issuers, then a change of
> certificate would require editing that file, and I suspect that will
> be more difficult for the staff at charge than just replacing a .crt
> file in a directory.

I disagree with that, but even if it were true, you don't have to change
metadata when a certificate changes, only when a key changes. A trust engine
can interpret certificates in metadata anyway it likes, and ours doesn't do
anything but extract the key.

> Maybe I'm too ignorant of SAML, but I think our scenario is not the
> normal federation, so we're using just a minimal part of it or of
opensaml.

I think you need to revisit the issue. If you don't have metadata, you will
reinvent it because the key alone is not sufficient to provision an IdP. You
need the other metadata unless you constrain the use cases heavily.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page