# Security Mechanism Direction Query

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

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Peiyi Ying: "upset!!"
- Previous message: William Maddox: "Re: Issue regarding inner classes"
- Next in thread: David Brownell: "Re: Security Mechanism Direction Query"

    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--

- Next message: Peiyi Ying: "upset!!"
- Previous message: William Maddox: "Re: Issue regarding inner classes"
- Next in thread: David Brownell: "Re: Security Mechanism Direction Query"