Subject: use case "skeleton" for delegation/intermediaries
Below is the model that I presented at the F2F last week for organizing use cases regarding delegation/intermediaries (aka 3-tier). I'll put it into official doc form and post to the TC site soon. I'll also provide a specific use case using IMAP as the backend application protocol and Kerberos as the security method. - RL "Bob" --- delegation and intermediaries use case skeleton RL "Bob" Morgan University of Washington / Internet2 October 28, 2003 This is a "domain model" for a set of more specific use cases that can be used to drive design. Concrete aspects of this model (eg basing it on browser profile) are chosen simply to limit scope of discussion. Components: C: Standard web browser, participating in SAML web browser profile (either Artifact or POST). M: Middle-tier web-based application service, acting as destination site of SAML web browser profile, and accessing backend service on behalf of browser user. B: Backend service, accessed by M, providing services via any of a large number of application protocols. AnA: SAML authentication authority, participating in SAML web browser profile (hence communicating with C and M), possibly commnicating with AtA. AtA: New SAML authority of as-yet-unspecified type, issuing assertions that support M's accesses of B. Flow: 1. C follows SAML browser profile, interacts with AnA and M, M obtains assertions from AnA and establishes security context with C. 2. M obtains "delegation token" from AtA. This is the step that may imply new SAML assertions, authorities, attributes, operations, etc. 3. M accesses B, using delegation token to support establishing security context for this communication that allows M to access B's resources on behalf of C (ie, the user of C). Options for making more specific use cases from this model: Choices for M<->B communication protocol: http, imap, pop, NFS, AFS, CIFS, webdav, SOAP, etc. Choices for M<->B communication security: Kerberos, SSL/X.509, WS-Sec, username/password, SAML, Digest-MD5, X.509 attribute certs, etc. Choices for threat model: B permits M to act as any user; B requires proof that M has recent signon from C; B requires proof that M has been delegated-to by C; etc.