Shibboleth Developers

[Chad La Joie <>]

The IdP has two flags that control encryption; one for nameid and one 
for assertions.  These flags on set on a per-relying party basis.  The 
IdP will encrypt something iff the flag is set to true and it can 
resolved an encryption key for the relying party (nominally this means 
the key is in the metadata).  If the flag is set to true and no key can 
be resolved it's an error condition.  If the flag is set to false no 
encryption is done.

How exactly we'll indicate attribute encryption still needs some things 
worked out.  It's possible we may not enable this in 2.0.

Tom Scavo wrote:
> On 10/31/07, Chad La Joie 
> <>
>  wrote:
> > Tom Scavo wrote:
> > > 1. The IdP asserts an SSO assertion with the following characteristics:
> > >   * The assertion is unencrypted
> > >   * There is a digital signature on the <Assertion> element
> > >   * The <AuthnContext> element distinguishes between two levels of assurance
> > >   * The IdP asserts a persistent, non-reassignable identifier (encrypted)
> > >   * The assertion may contain non-identity attributes such as ePSA 
> > > (unencrypted)
> > >
> > > * Can the Shib IdP 2.0 be made to issue such an assertion?
> > Yes.  Generally though, I imagine most people will encrypt the assertion
> > if they're pushing attributes in it.
>
> Thanks for the reply.  The above assertion doesn't expose the user's
> identity so it seems harmless.  In any event, will the Shib IdP 2.0
> encrypt the NameID and Attribute elements selectively (i.e., on a
> case-by-case basis).
>
> Thanks,
> Tom

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