From: Charlie Lai <charlie@angeles.eng.sun.com>
Message-Id: <199907302358.QAA01188@angeles.eng.sun.com>
Subject: Re: Regarding java.security.acl Package Deprecation
To: krosha@pdi-corp.com
Date: Fri, 30 Jul 1999 16:58:36 -0800 (PDT)
In-Reply-To: <199907141341.GAA20794@mail.java.sun.com> from "Rosha, Ken" at Jul 14, 99 08:46:00 am
hi,
> I've seen in the javadocs for this package, and in various other places,
> that the java.security.acl package is/will be deprecated or superseded.
>
> Very shortly, our company will begin development of web-enabled,
> distributed, server-based applications, in which we will need to
> authenticate users of our applications, and to validate their authorizations
> to our applications.
>
> The java.security.acl package seemed to have some of the base functionality
> which we need, but if it is going to be deprecated, we do not want to use
> it. Also, I've also read that the Java Authentication and Authorization
> Service (JAAS) API will not be available until the 'kestrel' (JDK1.3
> release).
>
> I would appreciate any help/direction which you could provide. Our need is
> immediate.
unfortunately, it does seem that you need the JAAS functionality,
but you need it to work in a Java 2 environment.
all i can say at this point is that perhaps it's best
at this point in time to use JAAS for authentication
(the LoginContext and supporting classes work in Java 2),
but then develop your own in-house way to perform access control
on the authenticated Subject.
in the short term, you may decide to implement ACLs similar
to those that are deprecated in the JDK. when you are
ready to move to the 'kestrel' (1.3) JDK platform,
then you can convert your access control code back to be JAAS-compliant.
the closer your ACL implementation is to the JAAS access control
architecture, the easier it would be to convert your code when
the time comes.
we resisted very much the temptation to make JAAS dependent
on 'kestrel'. our early designs were architected to work in Java 2.
only when we finally ran into insurmountable difficulties
did we succumb to adding new public classes to 'kestrel',
and have JAAS use those classes.
it may be that you'll find when you attempt to implement
your in-house access control implementation that you'll run into
the same issues (they deal with properly dealing with doPrivileged).
however, if you're able to restrict your environment such that
those scenarios don't occur, then you can happily ignore them.
thanks,
charlie