Security Mechanism Direction Query

Dan Rudman (rudman@idetix.com)
Fri, 5 Sep 1997 10:31:06 -0400

From: "Dan Rudman" <rudman@idetix.com>
To: <java-security@javasoft.com>
Subject: Security Mechanism Direction Query
Date: Fri, 5 Sep 1997 10:31:06 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01BCB9E6.D1751860
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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.

I note, however, that these APIs were not yet ready for commercial use. =
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?

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

------=_NextPart_000_0001_01BCB9E6.D1751860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">

We are in the beginning phases of developing a = client-server=20 product whose market requires that it be highly customizable in regards = to=20 security.  That is, we do not wish to actually tie the product to = any=20 specific authentication or access control method or protocol.  = Rather, we=20 want the end-administrators to be able to use whatever protocols make = sense for=20 their environments.  We would then distribute plug-in methods, such = as=20 Kerberos for authentication and LDAP for access control = lists.

JavaServer looked extremely interesting, as = did many of=20 the java.security and sun.security classes.

I note, however, that these APIs were not = yet ready for=20 commercial use.  Since security must be implemented in the = underlying=20 architecture of our product and is nearly impossible to retrofit in any=20 acceptable way, do you folks have a suggestion as to what direction we = should=20 take, or perhaps have any useful advice on how to proceed?

We are completely committed to using Java.

Thanks.

----------------------------------------------------------------= ------------
Dan=20 Rudman
Sr. Software Architect
Idetix, Inc.
850 Stephenson Hwy, = Suite=20 600
Troy, Michigan 48083
V: (248) 616-5040
F: (248) 616-5045=20

------=_NextPart_000_0001_01BCB9E6.D1751860--