Title: RSA Interop 2005 Guidelines
Other feedback on 30?
Bob
From: Thomas Wisniewski
[mailto:]
Sent: Wednesday, January 19,
2005 10:27 AM
To: Ciochon, Robert; samldemotech
Cc: Mark
Joynes
Subject: RE: RSA Interop 2005 Guidelines
Bob, 2
other comments:
29.
Since we are not using Soap, there is not need for a client ssl cert (so remove
9.2.4).
30.
For the x509 Subject name, I would like to restrict the data after the
uid=<user>,<xxx>, where <xxx> is constant for any provider and
defined ahead of time in the Appendix.
Tom.
-----Original Message-----
From: Thomas Wisniewski
Sent: Wednesday, January 19, 2005 10:20 AM
To: 'Ciochon,
Robert'; samldemotech
Cc: Mark Joynes
Subject: RE: RSA
Interop 2005 Guidelines
Bob,
nice job putting this together. Here are some comments on the use
cases/guidelines.
1.
General question for optional use case: Can we allow users to perform
additional federations from an SP. I.e., after the user federates, login in
again, and prior to or after they defederate, they can have the capability to
re-federate with the defederated IDP or they can have the capability to
federate with additional IDPs. Obviously this is something that we would take
them thru. Similar to defederation, which is something that might be done
after a user leaves the demo site, additional federations could be left up to
each vendor.
2.
Section 2.1 bullet 5. I'm not sure if this bullet is necessary (i.e., bullet 6
is enough). I.e., the use case is always from a solicited SP AuthnRequest and
not initiated at the IDP.
3. Section 2.2 bullet 7. The text says
"Initiate a redirect to...". I think you mean to say "Provide a link
to..."
4. Section 2.2 bullet 8. We should discuss,
for the federation case, when the user is required to log into the
SP. I.e., this can be before the IDP login or after. Are we saying it's up to
the SP or does it always have to be after the IDP
login.
5. End of section 2.2. You added a possible
requriement of displaying the xml documents that were exchanged. Do users
really want to see this? Also, what are you thoughts on how this is presented
(e.g., thru an external screen/log, or on the actual user browser
screen)?
6. Section 3.1 first sentence. You say four,
but I think you mean three (i.e., login, logout, and eAuth). I think that
breakdown works the best. I think you should move section 4.2 after the logout
discussion so it will be section 4.2. Then change sections 4.3 and 4.4 into
4.2.1 and 4.2.2. Basically following the same format/structure you defined in
the summary section 3.1.
7. Section 3.1.3, item 2b. s/on the SP is/on
the SP and is/
8. General comment on the optional use case. I
beleive the SP should state which name id format it is requesting, i.e., x509
subj name or a persistent id. This is done via the NameIDPolicy element. This
implies that the SP site, which lists the IDPs that support persistent
identifiers, needs to be smart enough to distinguish between the 2 types of
identifiers when calling and IDP. We had said this would be based on the user
name. However, if the answer to (4) above is that the user logs into the IDP
before the SP, then the SP does not know who the user is and therefore cannot
be sure which NameIDPolicy to use. I'm proposing the SP has additional smarts
in it (each vendor does this however they want) so that the IDP links on the
SP site hare two-fold. There are links for the base case IDPs and links for
the optional IDPs. Additionally, the eAuth use case always implies the base
case IDPs, hence x509 Ssubject names. Section 6, item 1, wording would
be updated accordingly.
9. Section 3.2, item 4 and 5. I don't believe
this requirement was mentioned on any call/email. I.e., obtaining user consent
is up to each individual provider. I suppose these could be optional steps but
they should not be required. I.e., when a user clicks on the IDP link at
the SP, they are consentng to federation. The same goes for section 6 bullet
4.
10. Section
3.2, item 8. s/SP triggering/SP via the IDP triggering/ The idea being
the user does another saml login at the IDP by initiating it at the SP
(basically a repeat of your item 1). To me it seemed like the text
in item 8 is suggesting that perhaps the user logs in at the
SP.
11. Section 3.2, item 9. s/on the web page/on the
SP web
page/
12. Section 4.1.2, item 3. s/of links to the SP
resources/of SP resources/ ^ s//(URLs)/ The text suggest the links
(actual URLs) are to the SP site when they are actually urls back to the IDP
with some TARGET=xxx or RelayState=xxx query parameter.
13. Section 4.1.2, item 4. s/resource links and/resources
and/
14. Section 4.2 (a question for Enspier). It's not
clear to me how the eAuth site knows which IDP the user has selected. Are
they using persistent cookie? I.e., I'm asking this to understand what can or
cannot be done at the SP. I.e,. if we do the eAuth use case for a couple of
SPs and then do the logout. Then a new user tries the demo, how does the eAuth
portal know this is a new request (i.e., the user is no longer logged on
to the intial IDP)? It would seem that the link back to the eAuth site would
require a CCID=<idp entity id> parameter much like the one that is sent
to the SP. Section 4.2.2 mentions using cookies to avoid propagation
(but I don't think this will work).
16. Section 5.1 item 1b. The Saml spec requires
subject confirmation data, s/MUST NOT/MUST/ and the data should
include recipient, notOnOrAfter, etc..... In general I think you can
remove section 3. This is just a restatement of what is mandatory in the
saml spec. I.e., similar to saying you need to include an IssuerName,
etc....
17. Along the lines of S3ction 5.2.1 item 1, an
AuthnRequest should either not inlcude an RequestedAuthnContext element
or should value this with run:...:Password.
18. Section 5.2.1,
item 2 and section 7.1, item 3. Why are there any restrictions at all on
SubjectLocality? Shouldn't this just be up to the
IDP.
19. Section 5.2.2,
item 1. Is everyone ok, with the 3 attributes. It seems like using postal
address (someone else suggested this attribute at a prior meeting) would add
to the personalization features of the
demo.
20. Section 8.1.1, bullet 1 and 3 AND
section 8.1.2 bullet 2. I thought we agreed that there would be one SP
resource for each SP and each vendor would only have one IDP. So change
the zero or more reference to there is one of these per vendor. Anything
beyond one would complicate the eAuth site, the links necessary on each
SP/IDP,
etc...
21. Section
8.1.1, bullet 3. s/URL to the idp logon page/The SAML entity id of the
IDP/ The entity id format is like a url but it is NOT a url and is not
meant to be the idp login url.
22. Section
8.1.2 bullet 3. Actually remove the IDP entity id reference from 8.1.1 and
move it here, note that this is a URL but an entity id
only.
23. Section
8.1.2 bullet 1. For issuer name, is this a string for display
purposes?
24. Section
8.1.4. I would say copy the list of vendors into A.2 as well. I.e., store the
value for <Vendor> in the appendix so it's easy to retrieve. Also, in
A.2 perhaps store the following data point: IDP-Basic, SP-Basic, IDP-Optional,
SP-Optional to indicate which vendor is doing what. It would be really helpful
to nail this down before the dry run.
25. Section
8.1.4, I would suggest sticking with the same password convention as the base
case. I.e., the password is the same as the userid. It just makes things
easier I think.
26. Section
9.2.2 bullet 5 s/qill/will/
27. Section A.2
and 8.1.1. The additional URLs that are necesary (in A.2 and in 8.1.1)
include:
-
SingleSignOnService (at IDP for base and optional
case)
-
AssertionConsumerService (at SP for base and
optional case)
-
SingleLogoutService (request) (at IDP and SP for
base and optional case)
- SingleLogoutService
(response) (at IDP and SP for base and optional
case)
- ManageNameIDService
(request) (at IDP and SP for optional case
only)
- ManageNameIDService
(response) (at IDP and SP for optional case
only)
28. Section A.2
and 8.1.2. The additional identifiers that are necessary (in A.2 and in 8.1.2)
include:
-
SP entity id (simliar to idp entity
id).
- Receiver Name
(similar to the idp issuer name). I.e., a display name for the
SP.
Tom.
-----Original Message-----
From: Ciochon, Robert
[mailto:]
Sent: Tuesday, January 18, 2005
3:17 PM
To: samldemotech
Subject: RSA Interop 2005
Guidelines
Hi,
Attached
is the first cut at defining the guidelines and use cases for the SAML
Interop at RSA 2005. Please send me any feedback, questions,
clarifications, etc...
Regards,
Bob
<<RSA2005-saml-interop.doc>>
Robert Ciochon
eTrust Development Manager
Computer Associates
San Diego,
California
(858) 625-6866
