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.
----------------------------------------------------------------= ------------
------=_NextPart_000_0001_01BCB9E6.D1751860--
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