6 messages in org.oasis-open.lists.security-servicesRe: [security-services] FW: [saml-dev...| From | Sent On | Attachments |
|---|---|---|
| Cahill, Conor P | Jan 17, 2006 11:51 am | |
| Prateek Mishra | Jan 27, 2006 2:07 pm | |
| Cahill, Conor P | Jan 27, 2006 2:34 pm | |
| Scott Cantor | Jan 28, 2006 12:46 pm | |
| Prateek Mishra | Jan 30, 2006 3:00 pm | |
| Scott Cantor | Jan 30, 2006 4:27 pm |
| Subject: | Re: [security-services] FW: [saml-dev] Constrained delegation | |
|---|---|---|
| From: | Prateek Mishra (prat...@oracle.com) | |
| Date: | Jan 27, 2006 2:07:41 pm | |
| List: | org.oasis-open.lists.security-services | |
These are good points; maybe the issue is more about capturing or recommending certain patterns of use vs. developing a new profile.
But before we discuss solutions, here is a question:-:
Is it important for SAML issuers and relying parties to distinguish between:
(a) A system entity that presents a SAML assertion that states "it" is named Joe; together with proof of possession..
(i) SAML issuer: must ensure by some means that only Joe is issued this token.
(ii) Relying party: validates proof, issuer information. May or may not have additional information about Joe (e.g., directory entry). Provides appropriate services to Joe against this information.
(iii) This is what the SAML 1.1 HoK modeled.
(b) A system entity that presents a SAML assertion, that states it is named server X and is acting for Joe; together with proof of possession.
(i) SAML issuer: must ensure by some means that Joe agrees/is aware of the issuance of the assertion to server X.
(ii) Relying party: validates proof, issuer information. May or may not have other information about Joe (e.g., directory entry) and server X (e.g., list of approved servers). Provides appropriate services to server X/Joe against this information.
(iiii) This is what SAML 2.0 HoK models.
--------------------- - prateek
They largely boil down to questioning alternate interpretations of the syntax (allowing for Ron's point about the language used to describe what it is that we mean here).
Yeah, to add some additional input, I would say that anytime an assertion is generated for a party that allows that party to use that assertion to establish a session at a relying party on behalf of a subject is, by definition, delegation.
If this needs clarification, then we should clarify the parts of the spec that aren't clear.
I'm not sure we need anything special in the assertion to identify this.
I would be interested in understanding an interpretation of the specs that lets an assertion generated for party A to use at party B with a subject that is not party A be anything other than delegation (of the right to represent the subject to party A when interacting with Party B).
Conor
--------------------------------------------------------------------- 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