Hi Michael, > No model today matchs all requirements. I think this access control or > voting functionality is not more than a new layer and we have a strong > problem because we have actually no good seperation between GUI and > functional code. I would propose something like this > > GUI code --> access control / execution code --> OpenCA API [...] > So I think we should rise the priority for the OpenCA API. Before we > start discussing the API itself we should think about the design of this > mechanism. So I make here a first proposal (there is no code or other > documents on this - only ideas :) )
Good idea. Some thoughts about architecture and modularization: Frontends (components accessing CA functions, not necessarily human interfaces) * GUI * SCEP * CLI * Batch * LDAP ... Application level (middleware, application logic) * OpenCA Highlevel API (used by all frontends) --- * Workflow engine (general request life cycle) * Batch processor --- * Authentication * Authorization * Approval (may be included in workflow engine) --- * Logging * Auditing --- * Data import/export ... Backends: * Database backend * Crypto backends > 1. The GUI or whatever creates the followoing stuff > - old object or hash (depends on the table) > - old object state (only important for objects) > - hash with parameters > - function of the API Sounds sensible. (What about the hash?) > 2. The UI sends the stuff to an execution engine. This engine checks the > required approvals on this action. If all is ok then it invokes the API > function. If something is missing then it writes the stuff to the > database: > - serialized_old_object > - old_state > - object_type > - serialized_hash > - api_function Suggestion: The execution engine implements the OpenCA API. The execution engine consists of the modules mentioned above in "Application level". > If we need an additonal approval then the approval is send to the > execution engine and the engine de-serialize the stuff from the database > and continues with step 2. Should be transparent if we abstract the problem in the workflow and approval engine. Idea: the Perl module Workflow looks good to me. http://search.cpan.org/~cwinters/Workflow-0.15/lib/Workflow.pm > If this design is acceptable then we have several problems: > > 1. error handling Is this a problem? The API functions could return a structure that contains error information (e. g. error code, description...) > 2. CA, batch and other private key and passphrase handling could be handled via tokens or cookies (not Crypto token in this context, but data structures identifying the adminstrative session) that are passed for each operation to the API. That way we could keep a logical session across API invocations. > 3. output handling Output could be passed via the API function return values. It's the frontend's responsibility to process/present the output properly. > 4. the authentication part of the access control is UI dependend > --> OpenCA::AC::AUTH::CGI + OpenCA::AUTH::Unix > --> OpenCA::AC::Policy (this is the old access control list which > must be replaced by the API functions) My suggestion is to have a general "Authenticator" object that is instantiated by a certain authentication method. The Authenticator could then create a token that is used to identify the session across API calls. The token might have a timeout that is reset upon each API call and/or has a fixed expiry time. > I think I should stop here to allow first a discussion about the basic > principles before we start coding. Perhaps some others have better ideas > or more experience on such stuff. I only used the default straight > forward method ;) Just started... :-) cheers Martin ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
