[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Update to WSS SAML Interop Scenarios w new SSL scenario + response to comments
Draft 3 WSS SAML Interop spec is attached and has been updated to
divide the first scenario into 2 scenarios:
1. Minimal SAML scenario
2. SSL SAML scenario
Diagrams have also been added to each scenario to give context.
In addition, below are my responses the comments that were received
from Ron Monzillo and where indicated those responses are reflected
in updates to the document.
Comments to draft 3 are wlecome.
Rich Levinson
Netegrity
-----Original Message-----
From: Ron Monzillo [mailto:ronald.monzillo@sun.com]
Sent: Monday, November 03, 2003 6:52 PM
To: Levinson, Richard
Cc: 'wss@lists.oasis-open.org'; 'hlockhar@bea.com'
Subject: Re: [wss] Update to WSS SAML Interop Scenarios w holder-of-key
Richard,
I'd like to pass on the following comments/questions on the 2nd draft of the
WSS SAML
interop document.
<Rich>
Note: Ron's comments for scenarios 1 and 2 have line numbers
that refer to the first draft of the spec. The appropriate line
numbers in the second draft which is what is now posted are included
in parentheses above the original for convenience.
</Rich>
!*********************************************
Comments on Scenario 1 (sender Vouches):
*********************************************!
(v2: 124)
1. para starting at line 109 - The comments regarding SSL cause me to wonder
if we should
have a scenario that explicitly tests sender-vouches where the sender uses
SSL to prove its
identity (1 hop) to the SOAP msg recipient and to bind the assertion to the
SOAP msg. Maybe
scenario 1 should be split into 2 cases one with SSL and one without. I
propose that we consider
the existing scenario 1 independent of SSL (and factor all the SSl
considerations out of its
description)
<Rich>
Scenario 1 is now divided into 2 scenarios, so there are now
a total of 4 scenarios which are:
Scenario 1. Sender-Vouches: Unsigned
Scenario 2. Sender-Vouches: Unsigned: SSL
Scenario 3. Sender-Vouches: Signed
Scenario 4. Holder-of-Key: Signed
</Rich>
(v2: 136)
2. line 121 : In this case, if a certificate is being sent, it is not being
sent to
verify a (XML-DSIG) signature. Its does not seem that any of C1.2 and C1.3
and C1.4 would
pertain to the non-SSL case.
<Rich>
For scenario 1 refs to SSL are removed C1.3, C1.4. However, I left
C1.2 there because the recipient probably should have a list of SAML
assertion issuers that they will accept assertions from - in the
unprotected
scenario, the Issuer attr is the only info the recipient has
indicating
the source of the assertion and the only basis for accepting or
rejecting it.
For scenario 2, the text of 4.1.4 was modified to indicate purpose
of
cert is for Requester identification.
</Rich>
(v2: 151-152)
3. line 136-137: "the request contains a plaintext SAML assertion...", I
think we want
the message to contain a SAML assertion containing one subject statement. I
am not
sure we need to say "plain text", and I don't see the value of checking the
subject against
a catalog of trusted users or the authority against the catalog of issuers?
It seems
that we could be less restrictive for this basic case of - can we exchange a
SAML
assertion in a SOAP msg.
<Rich>
A diagram has been added to each use case to provide context to
help explain the message flow and the basis for trust to motivate
the processing model.
I agree it is not necessary to specify "plain text", however, the
point
was to emphasize the vulnerability of the SAML Assertion without any
additional protection. So, I'll leave it in there for now unless
there is further sentiment that it should be removed.
All Requester messages contain only one SAML assertion, which
contains
only one subject statement. The statement was chosen to be the
AuthenticationStatement, because this seems to be a natural way to
introduce
a subject by an issuer. Attribute and Authorization statements seem
(at least to me) more likely to be used in scenarios where more
preliminary
context would be necessary to provide a realistic scenario. But,
in general, I agree that any type of statement should be acceptable
so I will remove the Authentication requirement.
I agree that there is no direct value in checking the user against
a catalog of trusted users, and that this unnecessarily complicates
a baseline scenario, so it is removed.
As far as the Issuer list is concerned, as mentioned above, in
scenario 1 without the issuer list there is no foundation for
a basis for trust and with scenario 2 (ssl) without the issuer
list our basis for trust is solely ssl and there is no tie to
using the saml assertion for any purpose, which might lead one
to question what value saml is adding to the scenario.
So, the only restriction in this basic case (1 and 2) is simply to
convey the assertion in a SOAP message and check that the assertion
is issued by a trusted issuer. In the ssl case (2) the
infrastructure
SSL setup should take care of determining that the Requester
certificate
is valid.
</Rich>
(v2: 162)
4. All of the elements of the table beginning at line 147 are marked
mandatory. Do we really
nead Timestamp and Conditions. IMO, we should drop would both of these (or
at least
Conditions).
As I mentioned above, it would also seem that we should be flexible about
the type of
Assertion, as long as it contains a sender-vouches confirmed subject
statement.
<Rich>
wsu:Timestamp is being kept to be consistent with the other WS
interop
scenarios.
Conditions can be dropped from scenario 1 to strive for a minimal
level of operability restrictions. However, for scenario 2
Conditions
with NotOnOrAfter and NotBefore is being kept for now because
it seems to me to be a fundamental attribute of an Assertion that
its
duration of validity can be intrinsically controlled and to show
that an
issuer can issue an assertion that has limited validity duration. It
seems to me to be desirable to present the assertions with some
capabilities,
except in the minimal scenario 1, rather than to be totally stripped
down.
</Rich>
5. As noted above do we need C.4.2.1 Timestamp
<Rich>
It is optional and explicitly not checked, but was kept to
conform with the original non-saml WS scenarios.
</Rich>
6. C.4.2.3 regarding Issuer Attribute; why must the Issuer attribute match a
particular value;
especially given that we are not requiring that the assertion be signed.
<Rich>
For base interoperability it appears to me to be desirable for the
Responder to be able to have some criteria for accepting or
rejecting
an assertion. The Issuer attribute is probably the minimal case of
determining whether the Responder gives any weight whatsoever to the
presence of a SAML assertion in the message. Issuer also provides
the foundation for interorganization interoperability by identifying
the organization that is responsible for issuing the Assertions
on which the Responder is going to rely.
Signature is a next level validation criteria - if the assertion is
not from a trusted issuer or recognized SAML authority, then why
even
check the signature. Granted, in the signed use cases that the basis
of trust IS the signature, it would seem to make sense at that point
that the Responder have some way to correlate trusted signers and
trusted issuers, which in many cases will be the same entity.
</Rich>
7. 4.2.3.1 Why are we requiring that a Conditions element be present
<Rich>
Scenario 1: Conditions will be removed for minimal operation.
Scenario 2: Conditions will be kept unless there is further
objection simply to demo interoperability wrt validity intervals
that may be specified w assertions. ow assertions are valid
indefinitely, which may not be typical operation, especially
for cases where the assertions are intended to be short lived.
In the SSL case the Requester is effectively signing an
assertion and may want to limit the possible duration of its use.
</Rich>
8. 4.2.3.2 NameIdentifier - I would opt for just requiring an Assertion
containing a
single sender-vouches confirmed subject statement.
<Rich>
NameIdentifier is being dropped as a requirement, but is being
left in the example as a field that should be ignored. The
section on SubjectStatement includes phrasing indicating non-reqd
elements may be present but should be ignored.
</Rich>
9. C.4.3 The WSS Saml Token profile is a little out of date WRT to the
core's description of
error codes (and the need to send responses). It currently does not define a
circumstance
that maps to "FailedAuthentication". Perhaps it should. As currently
written, the profile
describes mappings of problems to faults that would likely result in a
mapping
to FailedCheck under the indicated circumstances. In any case, we likely do
NOT need to
mandate what fault to return when we are doing something optional. If we do
need to do this,
we need to make sure the profile is in sync with the correspondence we are
requiring.
<Rich>
FailedCheck in the core spec refers to failed sigs, which are not
occurring in scenarios 1 and 2. I have changed it to
InvalidSecurityToken
which is more in alignment with both the profile and with the
scenario which is now testing only the issuer against the list
for validation.
</Rich>
10. C.4.3.3 Assertion - I don't see the value of this requirement. Ditto for
c.4.3.3.1
Conditions, and likely also c.4.3.3.2 Username
<Rich>
Issuer is still being retained as indicated above.
Conditions and Username are removed from scenario 1 as indicated in
reponses above. Username is removed from s2 as well.
</Rich>
[Just a comment] This may fall into the category of you teaching us how to
crawl before
we try to run, but I think it would be good if we could use STR's instead of
embedded
assertions for these scenarios. I realize it may be impractical for us each
to have an
authority online at which we could dereference the references. That said,
IMV, interop-ing
with references is likely at least as important as using embedded
assertions, and we likely
should devise a plan for testing with references (even if we fake out the
authorities).
<Rich>
I assume you are referring to WS core spec sec 7.4 which shows
a saml embedded in an STR. This scenario is based on the sv
case from the profile which doesn't use STRs.
If the profile spec were to be updated to include STR for the
sv example then we could add another use case to demo STR.
</Rich>
11. C.7 Expected Security properties - I don't think there is any
requirement that the
assertion be related to the "party" as described. Sender vouches, allows a
sender to
vouch for the contents of an assertion, independent of whether the subject
identified
by the assertion is itself.
<Rich>
I agree there is no need to include a User identifier in the
assertion to demonstrate interoperability.
Security properties section has been changed to indicate only that
the
service is available to messages with an assertion from a list of
specific
saml issuers.
</Rich>
!*********************************************
Comments on Scenario 2 (sender-Vocuhes signed):
*********************************************!
(v2: 289)
1. line 274: I would prefer that the certificate be referenced from the msg
as apposed
to being included in it.
<Rich>
OK, I will use an X509SubjectName to refer to the key.
</Rich>
2. D.1.1 UserName- List - as noted for scenario 1, I don't see why it is
necessary to restrict the
subjects. Is this a carryover form username password?
<Rich>
Agreed, user name list is not required for basic interoperability.
It has been removed.
</Rich>
3. D.1.2 IssuerName - List - perhaps this section should be removed
<Rich>
This addresses the usage of the Issuer attribute of the assertion.
There is a degenerate case where the Issuer attribute matches the
Subject of the certificate, but that may not always be the case
and it is not required by SAML. The purpose of the list is
to provide valid issuer names, which may be independently
mapped to certificate subjects if that is what the implementation
requires.
An alternative is to require the Issuer attribute match the
subject of the certificate in which case the list would not
be needed, but this seems to me an unnecessary restriction.
</Rich>
4. D.1.4 Requester Cert Value - IMO, the SSL qualification should be
removed.
<Rich>
Agreed, this was a typo.
</Rich>
5. D.3 general message flow - same comments about plain text assertion, and
I would
prefer that the certificate be referenced from the signature not "contained
in the signature".
Also, do we expect the relying party to validate the certificate (especially
if it is referenced)?
IF not, we should remove "validates the issuer certicate". In any case, we
likely should call
the certicate the "signer's certificate".
<Rich>
Plain text - again it is for emphasis, will leave in unless strong
objection.
As indicated in 1 above, a ref is now being used.
I am assuming we want the certificate to be validated, although it
is
up to the Responder how to implement this and there are no
restrictions,
except that operationally it is in the Responder's interest to do
so.
However, it would seem to make sense that the Responder have a key
store
where they can find the cert based on X509SubjectName.
As in all the scenarios a diagram has been added to clarify the
actors
and their roles in the scenario to help understand the context of
the
request and what the Responder needs to be looking for.
I am calling the certificate the "Requester's certificate" to
emphasize
that it is the Requester doing the signing, in contrast to the hk
case
where the Assertion Issuer is doing the signing.
</Rich>
(v2: 325)
6. Table begining on 310 - Again, I don't think Do we need to require
timestamps and conditions?
The table also shows a binary security token (note that it is not contained
in the signature),
IMO, it should be referenced from the signature. As noted above, I would
also prefer that we
accept any sender-vouches confirmed subject statement.
<Rich>
As above, timestamp is for consistency with other ws-interop specs.
As above, Conditions are going to be included to protect issuer
against issuing unlimited assertions.
As above, cert is now being ref'd so bst and str removed from table,
text, and sample msg.
</Rich>
7. Section D.4.2.4.1 requires the use of a relative URI to reference the
Assertion that
must be signed (I would prefer that we point to an STR, and that we feature
the STR
transform in the data reference).
<Rich>
I followed the SAML Token Profile V7 on this one, where the example
in section 3.4.2.3 does not use an STR. If the SAML Profile doc
is going to be updated along these lines, then I would agree that
we should use it so that we can be consistent, perhaps by adding
a new use case that demonstrates this capability.
</Rich>
(v2: 350)
8. Line 335 KeyInfo: same comment, I would prefer that we not include the
certificate,
but simply include its identifier.
<Rich>
OK, that has been changed.
</Rich>
9. line 343: same comment about requiring an AuthenticationStatement. This
seems to
prescriptive.
<Rich>
As above this has been changed to be any valid SubjectStatement.
</Rich>
10. D.4.3.5 defines recommended processing that I don't think should be
recommended.
There need be no correlation between the issuer (of the assertion) attribute
and the
subject of the cert or the subject of the assertion. If I understand the
scenario, the
assertion is not signed, so the value of the issuer attribute is
questionable, and in
sender vouches, whoever signed the msg + assertion is vouching for their
contents and
binding, including the subject of the assertion; which may be not be the
signer.
<Rich>
OK, the diagram that has been included identifies 2 actors: the
Requester and the Assertion Issuer. In general they can be
different entities, but they also can be the same entity.
However, in order to keep the focus on the SAML assertion, the
scenario is requiring that both the Requester cert be validated
and the Assertion Issuer be validated if they are different.
Also, I agree that from a trust perspective, that it is the signer
of the assertion + msg who is the real trusted party, but from a
a pure SAML perspective the SubjectConfirmationMethod is used
to validate the Subject of the assertion not the issuer of the
assertion. Therefore, I think it makes sense that the Responder
validate the Issuer and whatever relation exists between the
assertion issuer and the requester is up to the responder to
work out in the context of the preliminary agreements.
</Rich>
!*********************************************
Comments on Scenario 3 (holder of key):
*********************************************!
(v2: 492)
1. line 492: I would prefer that the certificate used to confirm the
assertion be
identified within the subject confirmation element as apposed to being
contained
within it. I don't have the SAMl spec at hand, but if we are going to say
contained,
we need to make sure cert containment is supported by SAML subject
confirmation.
<Rich>
The SAML spec specifies that a ds:KeyInfo element can be used
to specify the user key. This is from the dsig spec and allows
a wide variety of options including the ds:X509Certificate.
In general, the assertion issuer and signer must have the
user key to include in the assertion. Otherwise, there must
be some keystore that can be referenced by the ultimate
recipient of the assertion. Since the issuer has no knowledge
where the assertion might be going, it seems prudent to
make the assertion as self-contained as possible. Therefore,
both the issuer certificate and subject certificate are
included in the assertion.
</Rich>
2. Sections E.1.1 UserName-list may be important to the methodology but it
might
just be a carry-over from the username password scenarios. I would recommend
removing
or reducing the significance of the section (in this context).
<Rich>
I agree that the username list is not needed for the trust
mechanics of the interoperability. If the recipient trusts
the assertion issuers signature then the recipient has a
basis to trust the signature that can be verified by the
user key contained in the assertion. This should be reflected
in the updated scenario and diagram.
</Rich>
(v2: 505)
3. Line 503: Requestor cert value - we need to provide the cert, but its
identification
is accomplished within the subject confirmation element of the assertions.
<Rich>
This section has been modified to indicate that the Assertion Issuer
certificate is the one the Responder must be prepared to validate,
and that the User certicate is contained in the assertion. The
"requester certificate" is not an entity in this scenario any
longer except where the requester and user are the same entity.
</Rich>
(v2: 521)
4. Line 521: This para. implies some ordering of processing by its use of
the word
"finally"; although I expect that I may be reading more into the description
that was
intended. FWIw, wouldn't the order of processing be different that that
proposed.
Verify the signature on the asertion (incluing cert validation), verify the
signature
on the msg (including cert validation) and thus establish the subject(s)
associated
with the invocation.
<Rich>
I have revised the text to explicitly say the order is not
required, although all steps are necessary in any order. Also,
I have removed the dependency on the user being identified.
</Rich>
5. same comments as for the other scenarios questioning the need for
Timestamp and
Conditions.
<Rich>
Same as response above: trying to maintain consistency with other
interop specs on timestamp, and trying to use essential validation
features of validity duration on assertion except in the minimal
scenario 1.
</Rich>
6. IMO, requring authentication statements with holder-of-key is difficult
to
justify as why go through the trouble of obtaining an authentication
statement if
you are going to be required to prove your identity to use it.
<Rich>
As in the other scenarios above, I agree that authentication
statements
are not required and they have been replaced with any subject
statement,
although authentication statements have been left in the examples,
which
is also consistent with the profile v7 spec.
</Rich>
7. line 604: I think the value of the issuer attribute within the assertion
must
always match the cert used to verify the assertion signature.
<Rich>
I agree with you in principle, but the SAML spec says nothing to
guarantee
that and an issuer may not want to have their Issuer attribute be
the
same text as that of the Subject of the certificate. This is the
reason
that an issuer list is needed as a basis for establishing that
mapping
when it must be made.
Also, trust is based on the issuer certificate, not on the Issuer
attribute,
although there may be policy requirement that the issuer attribute
have
a particular value. i.e. the chain of trust flows thru the
signatures and
the Issuer attribute may be used to distinguish different entities
operating
under the same parent - ex. Issuer="XYZ-Marketing",
Issuer="XYZ-Accounting",
whereas the enterprise cert may simply be Subject="XYZ".
</Rich>
Ron
>Attached is the 2nd draft of the WSS SAML Interop Scenarios. This
>contains the holder-of-key scenario, which was not included in the
>first draft, as well as some minor updates to the original version.
>
>Comments are welcome and no additional updates are planned until
>comments are received.
>
> Rich Levinson
><snip>
>
wss-saml-interop1-draft-03.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]