S2ML Requirements analysis

Requirements

[R-AuthAttr] Communicate Authorization attributes
e.g. 'Alice has tier 1 credit' e.g. 'Alice is a finance administrator in X corp'
 
[R-AuthDecision] Communicate Authorization decision data e.g. 'Alice is allowed to access file xxx-yyy.txt'
[R-Integrity] Communications to be Authenticated
 
[R-MultiDomain] Support for communication across multiple domains
e.g. companies A, B, C use S, a hosting service for myERP. Each company connects to the same harware but has access to different partitions. Many different people work for A and S does not want to track which person at A has access to which specific resource at S. In addition company S also outsources its payroll to T and is a member of biz exchanges U, V. There is clearly a need for A to be able to manage all authorization data through a single system that communicates to S, T, U, V etc.
 
[R-SingleDomain] Support for communication of authorization data within a single domain
The case that a company is simply controlling access to its Intranet resources (Web server, mail, document store etc.) must also be supported cleanly.
 
[R-Authentication] Authorization data must bind securely to Authentication data
Here there is room for a lot of different architectural implementations that I don't want to call requirements.
 
[R-Session] Authorization data to be scoped by a 'session'.
At the very least some means is required to allow a client to control the use of credentials beyond the current request.
 
[R-OfflineAuthorities] Online and offline authorities to be supported.
[In most, if not all the scenarios I have seen widely discussed, there seems to be an assumption that the attribute authority is online and therefore accessible to a variety of entities (directly or indirectly). For particularly sensitive cases, I think it would be better to have the authority offline (and therefore harder to attack).]
 
[R-EfficientMessages] Should support efficient message exchange
Integrity checks such as digital signature can add excessive overhead to messages.
[R-RefusalReason] Inform client reason for refusal
Protocol should support means of providing client with information for recovery from authorization refusal
 
[R-Replay] Prevent replay attack
Servers should be able to prevent replay of previous authorization data.

Constraints

[C-XML] Protocol to be encoded in XML
Pretty much the staring point.
[C-Sig] Protocol to be consistent with XML Signature
Follows from [C-XML] IMHO. Any arguments?
[C-XKMS] Protocol to be consistent with XKMS processing of XML Signature KeyInfo elements
Should follow from [C-Sig]
[C-XTASS] Protocol to be consistent with XTASS framework
This is a slightly bogus 'constraint' since the intention is that we change XTASS to track changes in S2ML. Its like drawing the target arround where the arrow fell. But the arrow does have to fall somewhere that makes it possible to draw the target arround. Really this one comes down to extensibility.
[C-Open] Be 'open' and 'extensible'
[C-Mess] Minimize the number of messages required to support interesting use cases.
[C-PassUse] Should support users that only have password means of authentication
[C-PassCli] ?? Should support clients with no public key crypto ??
This does not follow from [PassUse]. A client could generate a public/private keypair and then use a password to authenticate itself to the authorization server which would bind to the just generated public key. This may not be generally acceptable in clients but the assumption of PK does simplify interdomain authentication issues considerably.

Architecture

Bit soon yet but some observations:

1) URIs are the Turing machine equivalent for the Web. This is handy when faced with [R-MultiDomain] and [R-SingleDomain] This is also handy since it allows artificial distinctions between resource names, roles, etc. to be avoided. In S2ML and Auth-XML I see a lot of 'nested' transactions that obtain different shades of authorization that to me can all be represented with a URI.

2) Binding of authentication data, there are some very different approaches:

  • Authentication establishes an authentic binding of an authentication token (i.e. a shared secret or a public key) to a UserName, Authorizations are securely bonud to the name.
  • The authorizations are securely bound to the authentication token itself, avoiding the need for to establish a name.

    3) There is also a need to support a particular corner case for HTTP cookie implementations. Here the authentication token and possibly the auth data needs to be inserted in either a cookie or a URL or something. Here I see two possible approaches

  • Try to encode all the data into the cookie or the URL, this has the advantage of simplicity but has the disadvantage of sending an awful lot of data arround. URL encoding schemes in particular could significantly bulk out a page of HTML. [Why didn't I suggest a Meta tag to allow extra data to be carried out with links instead of Referer?]
  • Most of the data is repetative and could be compressed or sent by reference. It is not really necessary to encode the authorization or authentication data itself, merely a secure binding thereto.

    4) Message flows, services There are several potential message flows: Flow

    1. Client C attempts to access resource B, is told to obtain auth credential from server A
    2. C obtains credential from A
    3. C repeats request, presents credential to B
    4. C makes additional request, presents credential to B
    5. [ C informs B that credentials are no longer to be accepted (logout)]
    This brings up a couple of questions HTTP is idempotent which is why these is no session notion in HTTP and why we need S2ML. What I should have done in digest is to provide a means of presenting a password en-clair the first time but bound to a second token to be used in future requests.

    4a) Server side redirect Another way to solve the problem is to have the server do all the communication with the auth server:

    1. Client C attempts to access resource B, is told to obtain auth credential from server A
    2. C request credential from B request is forwarded to A credential returned to C
    3. C repeats request (redirect), presents credential to B
    4. C makes additional request, presents credential to B
    5. [ C informs B that credentials are no longer to be accepted (logout)]

     

     

    The following are alternative approaches to satisfy R-EfficientMessages]

    [A-OptionalAuthentication] Authentication should be optional
    To Satisfy [R-EfficientMessages]
    Messages may omit authentication altogether
    [A-OptionalSignatures] Signatures should be optional
    To Satisfy [R-EfficientMessages]
    Messages may use a shared secret and Message Authentication code for Authentication in place of digital signature
     
     
    [A-Freshness] A means to determine freshness of authenticated messages
    To satisfy [R-Replay]
    Two main approaches, time stamp in authenticated data and validity interval bounds and nonce reply.
    Both cases would fit very well inside XML Signature SignatureProperties which would in solve the problem in a very high level generic manner that could be borrowed extensively in other protocols.
     
    [A-AuthzDecisionRefused] Metadata should be provided for denied requests.
    To Satisfy [R-RefusalReason] 
    If a request for authorization is denied, optionally metadata indicating why the request is denied should be returned. (An example might be "credit card expired".) (As an aside, I believe this is already implicitly allowed by the S2ML AzData element, because this can contain arbitrary element. I am suggesting it might be made an explicit element.)