# Re: Regarding java.security.acl Package Deprecation

Charlie Lai (charlie@angeles.eng.sun.com)
Fri, 30 Jul 1999 16:58:36 -0800 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andrew Morris: "Can you help me?"
- Previous message: Tianjian Yan: "Signed JDK1.2 applet does not go beyond security restriction at all"
- In reply to: Dieter Bratko: "Re: [iaik-jce] PKCS#7 verification"

    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

- Next message: Andrew Morris: "Can you help me?"
- Previous message: Tianjian Yan: "Signed JDK1.2 applet does not go beyond security restriction at all"
- In reply to: Dieter Bratko: "Re: [iaik-jce] PKCS#7 verification"