OpenSAML user discussion

[Xavier Drudis Ferran <>]

On Fri, Feb 08, 2008 at 04:31:12PM -0500, Brent Putman wrote:
> Hello Xavier,
> 
> Yes, you are correct, it fell through the cracks and is unfortunately 
> not implemented.  It probably won't be for 2.0, as we are in release 
> candidate stage and the feature set is pretty much frozen at this point 
> (unless we decide to make an exception for this, since it's more of a 
> plug-in).  I think we will still implement though, eventually, it's not 
> terribly complex.
> 

Ok, thanks. 

> I would ask and suggest though: Whose credentials were you looking at 
> needing to manage with this resolver?  If the relying parties' keys (for 
> any of signature verification; TLS authentication; and encrypting to 
> them) then you might want to look instead at the java-opensaml2 
> MetadataCredentialResolver, based on SAML 2 metadata.  That's a more 
> standard way of doing this in SAML.
>

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. 

We have a web app which used standard login and password based
authentication, and now is required to accept SSO with SAML 2
assertions from an IdP (possibly others in the future) which is
already set up. That is, that IdPs users already access an external SP
through SAML2 SSO and they want to access our web app with no changes
to their setup (well, just the URL where the browser post the
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).

Furthermore, the signing certificate's subject does not usefully
identify the issuer so as to distinguish trusted from untrusted
certificate holders.  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. 

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. 

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. Maybe if I could reference external certificate
files from the SAML metadata file, then it would be easier, but then they
would still find difficult to add new trusted issuers in the future. 
 
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.

> If it's just for your own local credential(s) for signing (and client 
> TLS and/or possibly decrypting ), that's usually a bit easier to handle 
> with your own app code, since it's a small number of keys (often in 
> reality 1) and you know implicitly who owns them (you're usually not 
> really "resolving" anything ).  Note we also have a 
> KeystoreCredResolver,  which just wraps a standard Java keystore, which 
> could be used for that purpose easily.
> 

Yes, even if it's not my local credentials. It's more like this. 
So I'll build an in memory keystore from the certificate files in 
the configured directory and use KeystoreCredResolver, I think. 

Thank you very much for your advice.


May I suggest though, to add a note in the java docs for

org.opensaml.xml.security.credential.FilesystemCredentialResolver

saying there is no implementation as of now ? 



-- 
Xavi Drudis Ferran