# Re: Security Mechanism Direction Query

David Brownell (David.Brownell@Eng)
Tue, 23 Sep 1997 11:17:18 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: brucew: "bug on page http://java.sun.com/security/signExample/index.html"
- Previous message: David Brownell: "RE: Certificate chaining"
- Maybe in reply to: Dan Rudman: "Security Mechanism Direction Query"

    Date: Tue, 23 Sep 1997 11:17:18 -0700

    From: David.Brownell@Eng (David Brownell)

    Message-Id: <199709231817.LAA09977@argon.eng.sun.com>

    To: java-security@javasoft.com, rudman@idetix.com

    Subject: Re: Security Mechanism Direction Query

Hello Dan,

Sorry for the delayed response. Too much e-mail, you know!

> From rudman@idetix.com Sun Sep 7 20:53:29 1997
> From: "Dan Rudman" <rudman@idetix.com>
> To: <java-security@javasoft.com>
> Cc: "James Korotney" <korotney@idetix.com>
> Subject: Security Mechanism Direction Query
> Date: Fri, 5 Sep 1997 10:31:06 -0400
>
> We are in the beginning phases of developing a client-server product
> whose market requires that it be highly customizable in regards to
> security. That is, we do not wish to actually tie the product to any
> specific authentication or access control method or protocol. Rather,
> we want the end-administrators to be able to use whatever protocols make
> sense for their environments. We would then distribute plug-in methods,
> such as Kerberos for authentication and LDAP for access control lists.
>
> JavaServer looked extremely interesting, as did many of the
> java.security and sun.security classes.

The JavaServer toolkit provides abstract "Realm" classes, and several
implementations which support the server sides of various authentication
protocols. Realms are pluggable and configurable components.

We currently have realms which support native OS authentication schemes,
SSL client authentication, simple shared password databases, and some
challenge/response protocols. No Kerberos, yet; nobody's asked for it,
unlike LDAP/PKI support.

> I note, however, that these APIs were not yet ready for commercial use.

What sorts of concerns did you have there?

> Since security must be implemented in the underlying architecture of our
> product and is nearly impossible to retrofit in any acceptable way, do
> you folks have a suggestion as to what direction we should take, or
> perhaps have any useful advice on how to proceed?

I'd suggest that you start looking at the JavaServer toolkit, in terms of
the server side issues involving plugging in to existing authentication
infrastructures. That's got the best developed server side Java
infrastructure of that sort. We have similar needs to plug into existing
authentication systems, since servers written with our toolkit don't go
into any single sort of environment. (We'd appreciate feedback on how
well the toolkit support your needs!)

Re the client side, that's an issue that needs more attention.

- Dave Brownell
JavaSoft

> We are completely committed to using Java.
>
> Thanks.
>
> -------------------------------------------------------------------------
> Dan Rudman
> Sr. Software Architect
> Idetix, Inc.
> 850 Stephenson Hwy, Suite 600
> Troy, Michigan 48083
> V: (248) 616-5040
> F: (248) 616-5045=20
>

- Next message: brucew: "bug on page http://java.sun.com/security/signExample/index.html"
- Previous message: David Brownell: "RE: Certificate chaining"
- Maybe in reply to: Dan Rudman: "Security Mechanism Direction Query"