OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] SOAP client cert authn and how it relates to SAML messages


> When SOAP is used to authenticate a client (client side certs 
> are used), is their a requirement in the specifications that 
> the client that has been authenticated "match" a SAML message 
> being sent. Or is this implementation specific.

Implementation specific. The mapping between message or transport-layer
authentication and the "issuer" of the message is out of scope of SAML, but
this is the chief reason Issuer is so critical, since it provides a
consistent starting point to perform the evaluation from. I can know who the
sender claims to be without starting from a physical (possibly varying)
credential.

> For example, assume there are 2 Attribute Requesters that can 
> send requests to a single Attribute Authority (SP-a and 
> SP-b). It seems possible that SP-a can authenticate to the 
> Authority using its own certifcate and then send a SAML 
> request message whose issuer name is that of SP-b.

Yes, and you'd better prevent that. ;-)

> Since the 
> SOAP binding was used with SSL and client authentication, 
> signatures and encryption were not used in the SAML request 
> message. What I'm trying to find out is if the SAML 
> specification allow this or forbid this explicitly.

Not explicitly, no. It's up to you to establish bindings between physical
credentials and SAML entities. We call that our trust layer, for lack of a
better term, and use metadata and metadata extensions to describe it.

This is not because of TLS. SP-A can sign the message with its certificate,
and still say the Issuer is SP-B. It's the same thing. There's certainly no
way you can assume that the subject of the certificate equals the SAML
Issuer in any physical sense, at least not if you want to have a workable
system.

> If they forbid it, meaning that the Authority must insure the 
> that client that authenticated is in fact the same as the 
> issuer of the SAML request, then what is the definition of 
> "the same as the issuer of the SAML request?" I imagine this 
> is implementation specific, where the client cert can come 
> from some set of issuers or perhaps only a specific set of 
> client certs are acceptable.

The language that was finally agreed upon was:

"If [the signature] is valid, then the responder SHOULD evaluate the
signature to determine the identity and appropriateness of the signer and
may continue to process the request or respond with an error (if the request
is invalid for some other reason)."

This language applies to signing, but the same principle applies. The spec
doesn't presume to know what the relationship is between Issuer and a key,
that's up to the implementation. I guess we could add something to that
effect somewhere.

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]