Tom Scavo wrote:
> On Wed, Nov 19, 2008 at 12:46 PM, Peter Sylvester
> <> wrote:
>
>> The usage of SAML assertions allows to disconnect some 'primary' identity
>> which
>> is available in an X.509 from some 'secondary' identity which is
>> established in
>> whatever way and which may be totally unrelated to the identities which are
>> present
>> in the X.509.
>>
>
> The identifiers in the certificate do not matter with respect to SAML
> Web Browser SSO (unless of course the SAML issuer decides otherwise).
> The only identifiers that matter are the Subject/NameID and any global
> identifiers that happen to be asserted as attributes in an
> AttributeStatement. In particular, the stuff in SubjectConfirmation
> are not identifiers for the user.
>
As said in another message, I agree, the last sentence is the key
part. I didn't
clearly see that. Somehow the brain was polluted by X.509 identities :-)
>
>> The identities present in the X.509 certificate may be
>> totally ignored by
>> a service provider and the identity provider after initial registration.
>>
>
> Yes, and we anticipate this to be the typical case.
>
Ok.
>
>> Furthermore, the SAML assertion is established for each act and normally
>> has a lifetime much shorter than the lifetime of a certificate.
>>
>
> True.
>
>
>> Nevertheless, the specification do not prohibit to use identities present
>> in the X.509 certificate in closed environments.
>>
>
> But this is totally out of scope with respect to HoK Web Browser SSO.
>
Yes, but there seems to be texts with SHOULD NOT that addresses this
scenario,
if the point is out of scope, then there is no reason to discourage
something.
>
>> The introduction could mention something about that an X.509 cert has two
>> purpuses:
>>
>> - The usage of the key (respond to some authentication challenge)
>> - The link to some "global" identity.
>>
>> The specification treats a case where the second part may or is not
>> used, i.e. a service provider only used the first part to
>> verify whether the saml assertion is presented by the holder
>> of the key and present whatever identity it is configured to present.
>>
>
> This is how it should be, I think. We can note the possible uses of
> the certificate in the profile (and I think we've tried to do this)
> but that text should not be in the normative parts of the document
> lest the reader misunderstand the intent.
>
First: I didn' gave a definition of 'global'. I don't mean a "unique"
type identifier
for everything, also entities can have all kinds of identifiers, and
several of
them. I just wanted to refer to 'non ambiguous'.
>
>> There is a use that would like to use whatever is in a certificate
>> in more or less diffcult ways for an application, but easier
>> for a "centralised" function or id server.
>>
>
> I'm not sure what that means.
>
Transforming the various fields and extension values in an X509 into
attributes of an saml attribut assertion, e.g. an email, or a web server
name,
some permanent identifier, etc. even keyusage etc
Most of these things are attributs and not part of an 'identity' . In X509
one should theoretically use attribute certficates, but this doesn't help
at all to create an assertion as in SAML.
>
>> My initial question was for a feature to return additional
>> identifier of the "subject" for example in the way outlined below.
>>
>
> But what you are proposing is an inappropriate use of
> SubjectConfirmation, I believe. That's not what SubjectConfirmation
> is for.
>
I agree.
> Tom
>
>
--
<http://www.edelweb.fr>
*Edel/W/eb* Peter SYLVESTER
Consultant Sécurité des Systèmes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : +33.1.40.99.14.14 / Fax : +33.1.40.99.99.58
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.com>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorité de racine
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
