OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]