|From:||Philip Hallam-Baker (pba...@verisign.com)|
|Date:||Jan 22, 2001 2:01:12 pm|
bin00000.bin - 3k
It is all very well to divide the document up into pieces and work on each separately. However it is difficult to specify core architecture without having any idea of the requirements at all.
I think we need to begin with a bullet point list of the requirements and constraints. We should probably start off with the full set of all possible requirements and narrow from there. This will be driven by the use cases in due course but should allow a start to be made on our piece. In any case I suspect that our requirements will be considerably more formal and technical that the use case group.
Distinction between requirements and constraints is probably somewhat arbitrary at this point. For some people the constraints will be at least as important as the functionality of the finished spec. i.e. if what is built does not work with XML Signature some of us will be going home regardless of what the beast will do...
Feel free to add, suggest moving terms arround etc.
[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.
[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.
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:
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
* In (4) how does C know if the credential recieved is still in scope?
* Logout (5) is a feature of password authentication processes. If the token itself is presented only way to stop reuse of the token is to tell the server not to accept it again. this is hyper unsatisfactory since it means that the resource server has to maintain state so that it knows which tokens are live and which are not. A better and more secure all round solution is to use something like digest authentication, the session can then be ended by deleting the token in the client [note that this may require some means for the resource to tell the client to delete the token].
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)]
5) HTTP binding
We can always clean up the HTTP binding by defining our own authentication scheme.