OpenSAML user discussion

[Xavier Drudis Ferran <>]

On Mon, Feb 11, 2008 at 10:49:36AM -0500, Scott Cantor wrote:
> > 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.
> 

Maybe I'm not seeing the wood for the trees but I'd say metadata is more
useful if you forecast many different use cases and you get something
in the assertions that you can match to the metadata. I don't even 
get entityIDs in the assertions, just some attributes I can use to 
find out the entity (institution) who has authenticated the user
that is trying to access my services. 

But I'll do some homework. I may say silly things meanwhile, so 
don't waste too much time reading me. 
 
> > 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.
>

No, I don't think we need revocation (well, at least we don't do it now).
But I guess certificates  will expire some day and need to be changed, 
if you just took some info from the subject and checked the signing CA, 
it should be less maintenance that a certificate directory. But we can't
do that, because certificate subjects are not useful.
 
> > 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.
>

In the Issuer I get the name of a centre, and I decide trust based
on the institution the centre belongs to. The information on what
centre belongs to what institution is in the DB (is small enough 
to have a cache in memory, but the DB is the source). I'm not claiming 
that's proper SAML, it's just what I get. It may not be proper
SAML because the issuer should be the institution, at least the 
signing certificate belongs to the institution. The center is just
the place the user is in, which needs to be logged too (and taken
into account in some cases for authorisation). I get the same information
from a SAML attribute, with the only difference that the Issuer 
carries a center name and the attribute carries a center id, a little
easier to look up. 
 
> > 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.
>

Ah. That's interesting. Thanks. It still takes some editing when 
a new issuer institution becomes trusted, but at least you don't 
have to change it every time the certificate expires.
 
> > 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.
> 

I believe my use cases are heavily constrained, but not by my design.
I just have to interoperate with whatever they have set up. Much of
what's set up makes little sense to me, but this may be because I lack
some information on their needs with the other applications they
have. I've now done a small part of FilesystemCredentialResolver which
allows me to do at least some tests with the certificates on a
directory, but I'll do take a second look at it before the final
design, and maybe I declare it all in a metada file. In our case, requirements
usually become clearer only after some tests, I'm afraid. 

I really appreciate your help, and your advice sounds sensible, I just
have to figure out how it fits with our requirements (including
clarifying some requirements). I just hope to stay without metadata
just until before I reinvent it, and then remember it's already
invented.

And I'll try to learn a little more on SAML. 

Thanks.
 
-- 
Xavi Drudis Ferran