Hi Martin,
> ...Frontends (components accessing CA functions, not necessarily human interfaces)
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?)
The new tables data, private key and statemachine are not storing objects. They store hashes.
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".
Yes, this is what I like too. A central engine which is feeded by the frontends. I hope this English is understandable.
Idea: the Perl module Workflow looks good to me. http://search.cpan.org/~cwinters/Workflow-0.15/lib/Workflow.pm
Ok, I will take a look at it.
1. error handling
Is this a problem? The API functions could return a structure that contains error information (e. g. error code, description...)
The problem is to find an interface which meets all requirements (batch, listings, searches, exports etc.).
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.
Cool idea.
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.
This is a little bit difficult because we have actually a lot of different forms, links and buttons. So we should analyze this part really carefully. I think for example that the complete user request generation should not be a part of the API (except serverside key generation). Why should the API know something about the special features of IE or Netscape?
So a classification of output would help a lot.
4. the authentication part of the access control is UI dependend --> OpenCA::AC::AUTH::CGI + OpenCA::AC::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.
Perhaps we should organize the stuff in some superclasses like AUTH, Session and Policy. AUTH is the prefix for authentication methods and every implementation provide us with some necessary functions. The same for the session classes (e.g. HTTP and Unix).
Perhaps I find some time in the next days to create some nice graphics. I think this is required for our design approaches to give other peoples a chance to understand what we are doing.
Michael -- _______________________________________________________________
Michael Bell Humboldt-Universitaet zu Berlin
Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
-------------------------------------------------------
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
