OpenSAML user discussion

[Chad La Joie <>]

No, the contents of the x509Certificate element is a complete, Base64 
encoded, certificate.  Also, note, that an X509Data element can contain 
multiple X509Certificate elements.

Håkon Sagehaug wrote:
> Hi
>
> Good to hear. one more, is the base64 endocing value of the certificate 
> which is in the <x509Certificate> element the same as the public key of 
> the certificate?
>
> cheers, HÅkon
>
> 2008/1/16, Chad La Joie < 
> <mailto:>>:
>
>     Yep, that sounds right.
>
>     If the system is going to see modest load you'll probably want to create
>     some bit of code that reads in the certs from the directory, parses them
>     into their Java objects, caches them and then just occasionally sweeps
>     the directory for new/removed certs.  Parsing the certs is a
>     semi-expensive task so you don't necessarily want to be doing that every
>     time you get a new message.
>
>     Håkon Sagehaug wrote:
>      > Hi
>      >
>      > So the setup currently is this, I've got a directory on a filesystem,
>      > not LDAP, that contains all the host certs I trust. When the
>     assertion
>      > comes in I want to first check if the public key inside the
>      > <ds:X509Cert> can be resolved to one of the certs in my trusted
>      > directory. If this clears I will see if the signature validates
>     against
>      > the public key from the saml assertion. Is this setup right?
>      >
>      > cheers, Håkon
>      >
>      > 2008/1/15, Scott Cantor 
> <
>     
> <mailto:>
>  
> <mailto:
>     
> <mailto:>>>:
>      >
>      >      > Is this right?For now I just evaluates the credential
>     against it
>      >     self for
>      >      > testing, which is built from the public key inside the
>      >     <dsX509Certificate>
>      >      > element in the saml assertion, it returns true so I hope
>     this is
>      >     right,
>      >     but
>      >      > since it's my first time I wanted some feedback
>      >
>      >     I can't tell if you're asking this in the sense of "am I grasping
>      >     how the
>      >     classes work" or if you're asking in a business context whether
>      >     "this is a
>      >     reasonable thing to do". I always try and emphasize this, so
>     forgive
>      >     me if
>      >     you understand this already, but...
>      >
>      >     NEVER evaluate the signing key against what's inside the
>     message.
>      >     KeyInfo is
>      >     a hint about what was used. The trust evaluation MUST compare
>     what
>      >     was used
>      >     against a completely separate source of trusted information.
>     In our
>      >     project,
>      >     we believe that source should be metadata, but as a
>     developer, you
>      >     can use
>      >     anything you feel is appropriate. As long as it's *not* the
>     KeyInfo
>      >     inside
>      >     the message.
>      >
>      >     Again, ignore me if you know all this. But a lot of people don't,
>      >     and they
>      >     end up with worthless code.
>      >
>      >     -- Scott
>      >
>      >
>      >
>      >
>      >
>      > --
>      > Håkon Sagehaug
>      > Research Assistant
>      > Parallab
>      > Bergen Center for Computational Science (BCCS)
>      > UNIFOB AS (University of Bergen Research Company)
>
>     --
>     SWITCH
>     Serving Swiss Universities
>     --------------------------
>     Chad La Joie, Software Engineer, Security
>     Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
>     phone +41 44 268 15 75, fax +41 44 268 15 68
>     
>
>  
> <mailto:>,
>     http://www.switch.ch
>
>
>
>
> --
> Håkon Sagehaug
> Research Assistant
> Parallab
> Bergen Center for Computational Science (BCCS)
> UNIFOB AS (University of Bergen Research Company)

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
 http://www.switch.ch