[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] Issue 101: Need additional SamlToken Assertion Elementsfor Holder-of-Key and Sender-Vouches
|
Attached is a preliminary proposal for resolution of issue 101. It
provides for implicit recognition of hk, sv, bearer Assertions that the client can recognize for the asymm, symm, and transport cases. This is not the only way that saml tokens can be represented, but it is intended to provide a starting matrix from which more complex cases could be derived. (Note: this was done without "Endorsing" tokens, because that would add extra complexity to sign the signature, which I do not believe is necessary to accomplish the objective here.) Please feel free to comment, question, and propose alternatives. Thanks, Rich Greg Whitehead wrote: How do you distinguish between Sender-Vouches and Bearer in that case then? Both are signed. -Greg On 8/11/06 10:09 AM, "Martin Gudgin" <mgudgin@microsoft.com> wrote: |
Below are the proposed minimal structures recommended for the
three major classes of saml assertions: holder-of-key (hk),
sender-vouches (sv), and bearer.
Interpretation of the presence of the specified token types in
the ws-sp structures below, effectively dictates the type of
assertion required. i.e. for example, when the policy is read
by the client, and it is found that the InitiatorToken must be
WssSamlV11Token10, then it is implicit that holder-of-key is
required, because that is the only kind of saml token inherently
capable of providing the required encryption and signing (because
it contains authorized key material in SubjectConfirmationData
that specifies a key the recipient should trust).
Really 3 roles here possible from recipient's perspective:
trusted-issuer: issuer of assertion
requestor: holder of assertion
initiator: holder of assertion key if one provided.
It should be assumed in all these cases that the recipient is
placing primary trust in the key that signs the Assertion. Any
secondary keys that are trusted derive the trust from the
signer of the Assertion.
For example, in each holder-of-key case, the hk Assertion
has been signed by a trusted issuer. However, in each
of these cases the key in the assertion SubjectConfirmation
identifies the key of the "initiator".
In the sender-vouches cases, it is the initiator who holds
the key that is trusted by the recipient, and the
assertion is a SignedSupportingToken that the
initiator "signs" when the request is sent on behalf
of a requestor. (Note: for transport-sv, the client
cert is required because this is the cert that "signs"
the assertion.)
In the bearer case, it is assumed the assertion is signed
by the issuer, and the initiator is simply transmitting
the request and the assertion on behalf of the requestor.
As such, even though the initiator will generally sign
the assertion for coverage, it is just represented in
the policy as a SupportingToken (not signed by the
initiator in terms of trust).
*******************************************************
Asymmetric cases:
asymmetric hk:
InitiatorToken: WssSamlV11Token10
RecipientToken: WssX509V3Token10
asymmetric sv:
InitiatorToken: WssX509V3Token10
RecipientToken: WssX509V3Token10
SignedSupportingToken: WssSamlV11Token10
asymmetric bearer:
InitiatorToken: WssX509V3Token10
RecipientToken: WssX509V3Token10
SupportingToken: WssSamlV11Token10
Symmetric cases:
symmetric hk:
ProtectionToken: WssSamlV11Token11
symmetric sv:
ProtectionToken: WssX509V3Token10
SignedSupportingToken: WssSamlV11Token11
symmetric bearer:
ProtectionToken: WssX509V3Token10
SupportingToken: WssSamlV11Token11
Transport cases:
transport hk:
TransportToken: WssSamlV11Token10
transport sv:
TransportToken HttpsToken/RequireClientCertificate
SignedSupportingToken WssSamlV11Token10
transport bearer:
TransportToken: HttpsToken
SupportingToken: WssSamlV11Token10
*******************************************************
Note: RecipientToken may not really be needed in the
asymmetric case to demonstrate the reqts for the
client, but I included it to complete the protection
of the messages 2 way, where client just relies
on recipient's X509 in general.
Note: the asymmetric and transport cases apply to
both wssv10 and wssv11. Symmetric is wssv11 only.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]