Hi Martin,
The new "OpenCA API" is implemented by the "OpenCA Execution Engine" which in turn uses a "Workflow Engine" to model the object modification workflow.
Perhaps we should not call it a workflow engine. A policy engine avoids conflicts with the statemachine in terms of the functionality and interpretations.
2. CA, batch and other private key and passphrase handling
Could work like this (idea/suggestion):
- The token itself is a random number (e. g. 128 Bit). It can thus safely be passed to the user e. g. in a cookie or in a hidden field. - The token is created by the Authentication Module after a successful authentication (which may also be 'none'). - Token validity can be - unlimited (until destroyed) - hard timeout (relative or absolute validity after which the token is not usable any more) - soft timeout (relative timeout that is reset after each API call with this token, keeping the session alive) - soft timeout with hard limit (same as before with maximum total validity) - Tokens can be explicitly invalidated via the Authentication API (logout) - Every OpenCA API function accepts and requires the session token. The token is passed/propagated internally across each call (whereever possible). - Token access is read-only for the API and every receiving function - The token is a key for a session object that is stored in the database. The session object contains information about user, authentication method used, validity of the token/session etc. It does not contain authorization information. - The Authorization framework is queried by each API function (and probably by subordinate functions) using the specified token. Thus every function can deduce if the current user (holder of the token) is allowed to perform the desired function.
Perhaps we can throw away our old session handling with this technology. If the session is stored directly in the memory of the server process or in a memory mapped file then we can store even passphrases in this area and the session handling is nearly transparent (except of the cookie or the session ID in the link). BTW it is perhaps a good idea to use IDs in links and no cookies but this requires some fundamental changes too - like always :) ... and we have already enough work for the next months ;)
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.
Perhaps I will find some time for some design work, too. I will contact you to coordinate this, OK?
OK.
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
