CAcert Code Development list.

[Mario Lipinski <mario AT cacert.org>]

Sorry for taking so long to take this up, but I am now back in business 
hopefully.

Am 04.01.10 08:29, schrieb Christopher Etz:
> In my opinion, the business logic should control the access to the data
> being read and transfered to the frontend applications.

Yes. The backend only passes data to the frontend based on the 
application and the user which has been authenticated for the application.

>  From what I have read in the wikis at dev.cacert.cl, I've got the
> impression that you plan to use OAuth for this. If I got it right, the
> business logic would serve as the provider, and the frontend application
> as the consumer.

We have our requirements on this. If OAuth fits them, we could consider 
them.

>     * During the authorization process, the user is directed to the
>       provider.
>       => This would result in having a part of the business logic
>       application with direct access for the user. Instead, I'd prefer
>       to only have the frontend applications as the clients of the
>       business logic application.

Having the api available for the user gives us the advantage we can do 
the authentication completely in the api as well as authenticating 
passing user data to the frontend application (we want to do this for 
certain applications). The API is accessible from public anyhow by the 
current design.

Another possibility would be hosting a trusted application for doing 
this authentication stuff.

Another point is: We do not want the user to pass his CAcert credentials 
to any frontend application (or maybe only the one mentioned above).

> Alternatives:
>
>     * Prerequisites:
>           o The business logic will authenticate the user. Therefore, it
>             is involved in every login to a frontend application.

Yes, BL is doing the authentication - there is no way to get around this 
imho.

>     * Alternative 2:
>       The login returns a handle (to a certain extent similar to a
>       OAuth-token, or a cookie), which must be passed to subsequent API
>       calls. A HTTP cookie is probably not ideal, since the client of
>       the business logic application is not a browser, but another web
>       application. Such a token probably needs a time-to-live and sould
>       be hard to guess.

We call this authentication stuff a token. I think how it is passed to 
the bl is not very interesting. It could be a HTTP Cookie, a parameter 
passed in the HTTP request or a field in the request body. There might 
even be more then one possibility.

--
Mit freundlichen Grüßen / Best regards

Mario Lipinski
Board member,                       E-Mail: 
mario AT cacert.org
Organisation Assurer (Germany),     Internet: http://www.cacert.org
Wiki/Issue admin
CAcert

Support CAcert: http://www.cacert.org/index.php?id=13
                http://wiki.cacert.org/wiki/HelpingCAcert

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature