Hi Michael,
>> Sounds sensible. (What about the hash?)
>
> The new tables data, private key and statemachine are not storing
> objects. They store hashes.
OK, understood.
>> 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.
OK, so we should define the following terms:
The new "OpenCA API" is implemented by the "OpenCA Execution Engine"
which in turn uses a "Workflow Engine" to model the object modification
workflow.
>>>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.).
Agreed. This might be a bit difficult. TBD...
>>>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.
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.
>>>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?
Right, this is difficult.
> 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.
Perhaps I will find some time for some design work, too. I will
contact you to coordinate this, OK?
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
