Changes between Version 1 and Version 2 of RefactoringSecurity


Ignore:
Timestamp:
07/08/06 15:56:52 (13 years ago)
Author:
lawrence
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • RefactoringSecurity

    v1 v2  
    1 == Refactoring Security == 
     1== Refactoring Security for DEWS == 
    22 
    3 In terms of NDG "login" ... we get authenticated ... and we should get the attribute certificate of the host we chose ... immediately ... so our credential "wallet" now includes a proxy certificate and a attribute certificate ... 
     3==== The smClient Interfaces ==== 
     4 
     5The NDG-alpha release architecture works, but needs to be enhanced for DEWS to allow easy integration with the W(C,F)S being built as part of DEWS. 
     6 
     7In particular, from an application developer's point of view, applications should be unaware as to the “state” of the security infrastructure.  This idea is encoded in the following figure: 
     8 
     9[[Image(source:TI12-security/trunk/architecture/uml/Application.jpg)]] 
     10 
     11Further, we anticipate that the applications we are deploying will be in practice legacy applications, so we want if possible to completely encapsulate the security infrastructure from the applications. This concept is depicted in the inheritance relationship: 
     12[[Image(TI12-security/trunk/architecture/uml/Legacy Applications.jpg)]] 
    413 
    514 
    6 Assumption: An application should be ignorant about security state! 
    7  
    8  * ApplicationStart 
    9    * GetCredential  
    10      * (i.e. get a cookie) 
    11  * DoSomething(toURI,withCredential) 
    12    * call check(toURI,withCredential) (I need an address for the check method, localGKWSDL) 
    13      * response yes, or 
    14      * noCredential, with instructions to get one (i.e. html response) 
    15      * no  
    16  * If noCredential, respond with message html including redirect 
    17  
    18 This is opaque to the security state. 
    19  
    20 So check has to take toURI, come up with a role ... look at credentials .. decide on a match ... 
    21 In hte case of browse I have to call check(role,toURI,withCredential) 
    22  
    23 Actually role is a (localRole,AAaddress) tuple  
    24  
    25 (This is wrong:) 
    26 LocalGK has the mapConfig files to be able to map a remote role (known from the attribute certificate 
    27 to a local role) and can do it without requesting a mapped certificate. This implies localGK is always 
    28 updated when the mapconfig file at a remote site is updated! 
    29  
    30