Dave,
hi.
Is is
also possible for you to place a link on the eAuth Portal site that would
remove the cookie that way as well? It just seems cleaner (for example if the
same user wanted to see the demo with another IDP). It seems like restarting the
browser might appear a bit of a hack. If no one else thinks this is necessary,
that's fine.
Tom.
-----Original Message-----
From: Ciochon, Robert
[mailto:]
Sent: Friday, January 21, 2005 12:46
PM
To: samldemotech
Subject: FW: RE: RSA Interop 2005
Guidelines
Date: Fri, 21 Jan 2005 07:42:38
-0500
To: "samldemotech"
<>
From: Dave Silver
<>
Subject: RE: RSA Interop 2005
Guidelines
Cc: "Mark Joynes"
<>
The E-Auth Portal uses a cookie, but it is not persistent. This
is for privacy reasons. We recommend that the user start the demo by
opening a browser, and end the demo by closing the browser. If
the user forgets to close the browser, the presenter can do so before the
next demo. Please let us know if you have additional
questions.
At 02:06 PM 1/19/2005, Ciochon, Robert
wrote:
Hi Tom,
Thanks for the feedback. Please see my comments
below.
Everyone,
I have flagged a few items that I would like
additional feedback on. Please respond or I'll bring them up on the
call.
Dave
Silver or Terry McBride,
Would you please address Tom's question
below?
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).
Regards,
Bob
From: Thomas Wisniewski [mailto:]
Sent: Wednesday, January 19, 2005 7:18 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.
[bobc] I think we
are all concerned with introducing too much complexity into the demo
scenarios due to limited amount of time we will have with each customer
and the amount of time to test and verify each scenario. The
optional use case was designed to demonstrate federation clearly and
simply. Could someone show more? Sure, the tools are all
there. But I would prefer to keep things as simple as possible at
this stage.
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.
[bobc] I'll leave it in. Better too much...
3. Section 2.2
bullet 7. The text says "Initiate a redirect to...". I think you mean to
say "Provide a link to..."
[bobc] I will change that.
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.
[bobc] We can discuss this further on the call to see
what people agree on.
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)?
[bobc] This was a
carryover from last year and is up to each vendor if or how they display
this. It is basically a trace log to lend some credence to what is
being shown.
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.
[bobc] I
actually meant SP initiated login, idP initiated login, SP initiated
logout and idP initiated logout as the 4 base SAML cases, and then eAuth
as a separate 5th case. I'll have a look at the section setups when
I update it next time.
7. Section 3.1.3, item 2b. s/on the SP is/on the SP and
is/
[bobc] WIll change
that.
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.
[bobc] I was
heading in that direction myself on the last call when people said they
could just figure things out from the user name. Let's discuss this
some more on the call today since I think your method will simplify things
for the demo staff.
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.
[bobc] I think it was
mentioned in passing when discussing this case and was never explicitly
called out. I know this was a big deal in the Liberty Alliance
specs. Let's discuss on the call.
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.
[bobc] That is more accurate and will be
changed.
11.
Section 3.2, item 9. s/on the web page/on the SP web page/
[bobc] I will change this.
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.
[bobc] I will change this
13. Section 4.1.2, item 4. s/resource links
and/resources and/
[bobc]
I will change this.
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).
[bobc] Moved up for reply.
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....
[bobc] Some carryover from last year's doc.
I'll take it out if people find it confusing.
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.
[bobc] Anyone else have feedback on this
one? It is a carryover as well.
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.
[bobc] I gather this was added last year because
people had some problems with DNSName. Anyone else have feedback on
this one?
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.
[bobc] Anyone else
have feedback on this?
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...
[bobc] Not every
vendor is required to provide both an SP and an idP. As I recall,
someone mentioned that last year not all vendors provided both. That
is why the zero. I will change the "more" to "one".
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.
[bobc] I was using the recommendation in the spec,
especially since we are only using front channel bindings. I was
trying to make it simple, but can change it if it is not accurate for our
demos.
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?
[bobc] I believe
that is how it was used last year.
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.
[bobc] I plan to add that in somehow once I have who is supporting
what.
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.
[bobc] Or should we make just one password that is the same for all
users for both base and optional? Anyone else have feedback on this?
26. Section
9.2.2 bullet 5 s/qill/will/
[bobc] I will fix that.
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)
[bobc] Will expand those sections
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.
[bobc] Will add
receiver name. SP entity id is same question as idP.
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
