[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Technical Overview - comments request
John, here is my feedback on the Tech OV. Note that I did not have time to review the SAML 1.1 vs. 2.0 comparison.
99: Perhaps say that relying party is sometimes called SAML requester. The last paragraph in section talks about SPs and IDPs. But there really is this notion of a requester (e.g., an Attribute Requester that was added to the metadata post SAML std). So perhaps line 102 should say SPs or Attribute/Assertion/Authentication Requesters.
103: s/services/service/
104: s/IDPs/IdPs/ this should be done everywhere in the doc to follow the SAML version vs. the Liberty one.
112: delete line
113: s/SSO and Cross-Domain/Cross-Domain SSO/
130: s/user-centric/user-centred/
131: s/user experience/user-experience/
131: another benefit is that administrators do not need to manage these identity mappings. Rather the actual user can manage them (see my comments on section 4.3 related to User Federation Management)
138: reference to AirlineInc.com needs italics -- this comment carries throughout as there is a mix of italics and non-italics in the doc. Goes for CarRentalInc.com as well.
139: s/web site (CarRentalInc.com/web site/ just following the model in line 137-138.
141: s/session/user
148 and Figure 2 label: s/linking/Linking/
Figure 2: The IDP is missing the user id as "johndoe"
Figure 1: it might be helpful to show "Gold Member" somehow. Perhaps just listing johndoe: Gold Member, xxxx at the IDP and then having something at the IDP that maps Gold Member to some Elite car rental status.
168: add attribute to the list of transfer items.
197: s/an/a/
217: s/value/value or format/ the idea of changing format is n/a here. Only the identifier value can change. The specs have been corrected (PE12).
222-223: Add that the logout can also occur due to a provider site wishing to do so. E.g., the user is revoked at the site or the Admin has some reason to log the user out.
276: s/within/withing/
Figure 5: I would suggest adding required elements/attributes to this example. Specifically: SubjectConfirmation of ...bearer for the Subject which requires Recipient=https://www.sp.example.com/SSO, NotOnOrAfter, and InResponseTo. Also add AudienceRestriction/Audience=https://www.sp.example.com
Figure 6: change http://www.example.com to https://www.idp.example.com. (note the use of https and specifying idp in the host name). Also, the AssertionConsumerServiceURL should point to https://www.sp.example.com/SSO as this is the SP's url. Whatever value you use here, it should match the Recipient value in Figure 5 for consistency.
Figure 6: The ProviderName value of "string" seems odd? Shouldn't this be the requesters display name, like "Car Rental Inc Company" or "An SP Example"
345: s/ID (response ID)/Response ID/
345: s/Version/Version numbers/
397 s/NameID/NameIdentifier/ to keep with the actual element name.
418: appears to have a space as the first char in the sentence.
242: / / . /
433: s/transmit it/transmitted/
439: s/WSS are by/WSS by are/
441: appears to have a space as the first char in the sentence.
450: s/an/a/
521 and 523: which document is this referencing in XACML?
530: s/an XACML//
531: s/an/a/
546: s/ and the use of ... is recommended/ and the use of ... are recommended/ Chaging are to is and removing the extra space in "are "
554: s/ / - /
555: s/Profile/Profiles/
556 s/Federation Use Cases/Federation
556: Add another profile for Single Logout (I think this should be on its own or perhaps get rolled into SSO). I think it does not make sense to try and tie this into ID Federation. My suggestion is to make this its own category.
559 s/models/model/
561: Perhaps rework this sentence -- it seems hard to understand. In the end there are eight combinations not 6 -- based on the allowed binding techniques allowed.
562: s/;/.,/
568: s/artifact is carried/artifact carried/
570: s/artifact/assertion/ in saml 2 this is a generic mechanism, not just for assertions.
570: s/MessageHandle/AssertionHandler/ same as above.
General Comment: sometimes you capitalize Service Provider and Identity Provider and sometimes you don't. Perhaps make this consistent throughout. The SAML specs tend to user lower case.
569: s/of the Identity Provider (called the Source ID)/of the Identity Provider/
572: s/IDP/user/
573: s/SAML artifact resolve request/SAML request/
573: s/asking it to dereference the supplied artifact./asking it...user./
574: s/back embedded in a SAML artifact response/back in a SAML response/
577: Delete the first sentence (seems like it is misplaced here).
Figure 12: Perhap label the arrows as 2 and 1 (PUSH) and 2 and 1 (PULL) and add a third arrow from IDP to SP with label 3.
583: s/SP Initiated/SP initiated/
584: s/and potentially authorization/and authorization/
585: s/an authentication request/the request/
585: s/obtain/provide back/
Figure 13: Perhap label the arrows as 2 and 1 (IDP init) and remove the pointer to the browser. The for (SP Init), label the arrows 1 and 2 (and remove pointer arrow to browser). Also add a third arrow from Browser to SP calling it 3.
General: For consistency, you may want to s/www.idp.example.com/www.xyz.com/ and s/www.sp.example.com/www.abc.com/
590 and 598: s/an existing session context/current logoin session/
597: s/user attempts/user attempt/
599 -601: I really think you need to change the wording here from "defining the user for which" ... to something like "defining the identifier format for which". I.e., the typical usage is that the SP does NOT know who the user is at all (and that's the main point). They just say authenticate whoever the browser user is and use this format (e.g., ...X509SubjectName).
General: s/an HTTP/a HTTP/
604: s/an existing/any current/
602 and 611: s/a user/a user/
604-605: Change this paragraph to be the same as 634-636.
613: s/Consumer service/Consumer/
614: s/If this, and the Assertion validate correctly/If this validates correctly/
615: s/ with/ with/
615: instead of saying with a cookie... just say a security context is established at the SP (how this is done is implementation specific).
617: Add: If the access check passes, the TARGET....
General: **Almost all** comments from 588-617 apply to the next 7 user cases and some of the id federation use cases as well. This also applies to artifact related comments below. They would apply to all the use case sections that involve artifacts. It also applies to other comments like use of Inter-site Transfer Service, etc...
640: s/specification mandates/specifications mandate/
660: s/artifact/assertion/ in saml 2 this is a generic mechanism, not just for assertions.
661: s/MessageHandle/AssertionHandler/ same as above.
663: s/service provider/Inter site Transfer Service/
Figure 16: All the wording in this section says an HTTP Post (HTML Form) is used to send the artifact to the IDP, however the figure shows an HTTP Redirect being used. So if you stay with HTTP POST (HTML Form), then item 2 should be split into two numbers; similar to Figure 14. Else, change all wording in the section to say HTTP Redirect is used.
666: s/Source ID/source-ID/ like in 660.
670: s/by the service provider/by its Inter-site Transfer Service/
678: s/mandates/mandate/
General comment related to the figures and verbage aroundthe use of Artifact. I think you need to make mention of the Artifact Resolution Service (vs. saying Saml Responder). Additionally, the figure should show an Artifact Resolution Service. Currently the arrow point an incorrect service. E.g., Figure 16: shows the artifact being resolved by the SSO Service which is incorrect?
722: Remove the comment about "In most implementations...." Or add this to all 8 use cases. I think it fine to say if the assertion is validated, then a session context is established (that is the general case).
777: mentiond that the artifact (for AuthnRequest) uses HTTP Redirect (as the figure indicates). This ties into my comments on Figure 16. So perhaps for the AuthnRequest, use the HTTP Redirect binding for SAMLart and for the authn Response, use HTTP Post. This way the reader can see both options. This would mean changing the wording in these cases to talk about HTTP Redirect with query string SAMLart.
828: s /Provider (www.xyz.com)/Provider/ -- or call it www.idp.example.com as mentioned above.
829: s/at a service provider/on a remote server/
830 (and anywhere it may apply): s/xxx HTTP POST/xxx POST/ where xxx doesn't end with HTTP.
838: s/specification mandates/specifications mandate/
842: s/provider's/provider'/
850: s/it/its/
850-851: s/i.e.,/that is/
General comment on the 8 use cases: The wording varies between these in many cases even though the processing is the same (if you know what I mean). I don't think that necessarily bad, but as a read, it seems to suggest there is something different going on when there really isn't (like sometimes the assertion is validated and sometimes it's not). Another example, sometimes it says the browser uses an HTTP GET is used to retrieve the TARGET, and sometimes the redirect just causes the browser to access the TARGET.
882: I'm not too familiar with ECP, but I would have expected at least one of the use cases to actually be "an enhanced client?"
886: I don't understand this use case?
887: s/cannot/can not/
903: Which Service endpoint is this going to -- I believe this is the Single Sign-On Service?. Add this verbage.
Figure 22: Add Single Sign-On service and Assertion Consumer service.
912 and 916: Change SSO Federation term and call it "Implied Federation" and change Federation during <AuthnRequest> to "SSO Persistent Federation". Basically, the first case is a trivial, older case and is really not tied to SSO so much as opposed to just being implied by the attributes being returned. See below for more comments
913: s/SAML 1.1/SAML/ with SAML 2.0, you get federation capability with SSO.
918: s/User Persistent ID Federation Management/Federation Termination/ See below for more comments. I know there seems to be a wish to include the saml protocols/profiles in this section but I think what you really want and I believe it's the right thing, is to specify ID Federation use cases (so you may use 1 or more profiles in order to accomplish this). This new use case I'm proposing would use MNI for Termination and refreshing the current id value, it would also federate a user using SSO. And offer a local delete or refederation option.
919: I would strongly recommend not to include Single Logout in ID Federation but rather make it its own section. It really has nothing to do with ID Federation but rather SSO Logout.
941: s/Consumer service/Consumer/
964: s/Assertion Consumer service/Service/
968 s/attributes./attribute/
973-974. Delete the first sentence -- this is incorrect. Whether push or pull is used, is irrelevant to this use case. Federation can work in both modes.
New Use Case: Create a new use case similar to SSO Persistent Federation. Call it "SSO Transient Federation". In some cases this is similar or rather expands on Attribute Federation and it works just like SSO Persistent Federation. The idea is that the transient id is only used for one SSO session and then discarded. The reason it expands on Attribute Federation is that it is good for the session. This allows the SP to re-use the transient id and call the IDP or saml responder at the IDP to perform more tasks (e.g., to run another attribute query to obtain further information on the user or to issue an authorization decision query).
I guess Attribute Federation came out of SAML 1.x but I would assume that SSO Transient Federation would replace it down the road. For example, it's not clear on how the IDP knows to send back dummy user data (meaning the NameID is irrelevant). I guess the SP just asks for an unspecified NameID and which ever one it gets back, it just ignores that?
Figure 25: I think the focus of this figure is incorrect. It basically emphasizes SSO (which was in the last chapter). I think it should really emphasize the id federation pieces. This includes enhancing the identity store to show persistent ids. For example:
IDP says: jdoe 12345 -> 67890 at AirlineInc.com.
SP says: johnd 67890 -> 12345 at CarRentalInc.com.
972-1002: similar syntax comments from 923-946 apply here as well.
998-1001: s/original/TARGET/ TARGET does not apply here, rather the original resource the user went to.
1003: Change this section to be User Federation Management. The idea is that this is an interface available to the actual user in order for them to manage their own id federations. It should include the MNI termination example as well as MNI NewNameID (aka Refresh) example. It shoudl also include a "federate with these other available IDPs" which basically does an SSO AuthnRequest/Response but for the purpose of federating with other IDPs. Lastly, it should offer a re-federation or local delete option for the cases where the federation data how become "orphaned/stale" (invalid). Think of the case where the IDP is no longer available/around but the SP still has the id values for it in its repository. This provides a means to remove that stale data.
Figure 26: should not have a Resource box in it.
Figure 26: Add/Update Figures for this use case, so it includes the peristent ids on the IDP and SP. Similar to comments on Figure 25. Perhaps show a figure where there is an ID federation with 1 IDP and there is another IDP available (that the user has not federated with) and the IDP is listed as a potential IDP for the user to federate with.
General comment on all use cases. There are times when you mix the terms service provider and identity provider vs. AirlineInc and CarRentalInc. And sometimes both are referred to. Perhaps change this to the same style, if time permits.
1043: s/returns a/send a/
Figure 28: should not have a Resource box in it. I also think you should add another SP where arrows 3 and 4 point to. This will clarify the SLO across multiple, different SPs.
In addition to making single logout its own section (from ID Federation), I think it would be good to show at least 2 use cases. One where we are SP initiated (current one) and a new one that is IDP initiated. The Figure would show the IDP sending a logout request to two SPs. It could also be the case that the first logout request uses HTTP Redirect, while the second one uses SOAP to instill the idea of both binding could be used within the saml logout request from the user.
Figure 28 and new Figure to be added: Change label from Multiple Logouts to SP-Initiated Logout and IDP-Initiated Logout.
1055: s/document./document/
1212: reference CD-04 still.
1208: Are the SAML document IDs correct? Are these now referred to as "saml-xxx-2.0-os?"
Tom.
-----Original Message-----
From: John Hughes [mailto:John.Hughes@PACONSULTING.COM]
Sent: Friday, June 17, 2005 3:15 AM
To: Security-Services (E-mail)
Subject: [security-services] Technical Overview - comments request
Please can I have any comments on the Technical Overview asap - in particular on the new section 4.3 which goes through a few different use-case Federation examples. So far I've only had some from Prateek.
For instance does section 4.3 have as much coverage as we would like? Observant readers will notice that a Name Identifier Mapping Protocol example is not included - nor is the Liberty "opt-in" concept mentioned (except briefly in section 2.2)
John
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS
at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]