# Re: Authentication to an ACL realm.

David Brownell (db@Eng)
Sun, 26 Jul 1998 09:32:52 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jaidev: "Having a problem still"
- Previous message: goldstein@pousa.com: "SUCCESSFUL WEBSITE SALES!!!"
- Maybe in reply to: Lasse Tunturivuori: "Authentication to an ACL realm."

    Date: Sun, 26 Jul 1998 09:32:52 -0700

    From: David Brownell <db@Eng>

    To: Lasse Tunturivuori <Lasse.Tunturivuori@sqc.fi>

    Subject: Re: Authentication to an ACL realm.

ACLs are not really the primary point of realms, note! Think
of them as customizable user databases. The ACLs are there as
part of the policy administration framework for making user
authentication usable for its primary task: Authorization.

There are two basic approaches. One uses the authentication
schemes built into HTTP ("basic auth", "digest auth"). The
other uses a custom protocol, layered over HTTP(S) using some
client code that can do a POST, and a servlet.

Most worthwhile authentication protocols will need the latter
approach, and will need a custom realm to hold the custom user
authentication data. HTTP's own authentication support is weak.

The most common authentication schemes that are proof against
passive attacks (and some active ones) are challinge/response
schems. You'll notice there's a com.sun.server.realm interface
defined for (single) "ChallengeResponseAuth". You'd define a
custom realm subclass which provides "User" objects implementing
that interface. The realm would store whatver authentication
secrets are used in the protocol, and issuing a new card would
cause the realm to be updated with that card's data.

Then the custom protocol between client and servlet would look
something like this -- probably using HTTPS if you're more than
nominally concerned with security:

Client Servlet

"Authenticating as XYZ" -->
<-- "OK, respond to this challenge"

"Here's my response" -->
<-- Accept/Reject/Lure

Re how to write the servlet -- it's just like any other servlet
that handles POST: implement doPost(), pull the data in from
the input stream. System structure is the harder part.

That should be passed straight down to the card, which would
do whichever computation was desired. Ideally it's more than
just hashing the challenge with the card ID, since the card
ID is public ... hashing it with a (shared?) secret created
as part of issuing the card would be strongly advised (and of
course, don't let the secret off the card into the browser!!)

Alternatively, the card could hold a private key and an
associated public key certificate. That assumes your card
has enough horsepower to run a public key authentication
protocol. If it does, it'd be very interesting to tie it
to the SSL client authentication scheme in some secure way.

- Dave

Lasse Tunturivuori wrote:
>
> Hi.
> I am working on a project, where the user authenticates himself to a
> server with a JavaCard. My problem is, how do I write a servlet in order
> to authenticate the user with information from an applet, and not
> directly from a Web-browser?
>
> With best regards,
> Lasse
> --
> Lasse Tunturivuori
> SQ Consulting Oy
> http://www.sqc.fi/
> http://www.sqc.fi/~tuntula/

- Next message: Jaidev: "Having a problem still"
- Previous message: goldstein@pousa.com: "SUCCESSFUL WEBSITE SALES!!!"
- Maybe in reply to: Lasse Tunturivuori: "Authentication to an ACL realm."