Last revised: 08Aug2003 GLGTable of Contents
This document describes the concrete Authorization implementations provided in the Authorization Toolkit for Java. If you haven't already read the overview, you should.All necessary JARs and JNI-libraries are provided in ready-to-use form. You don't need to compile anything in order to use any of these concrete Authorization imps on any supported platform. You may recompile if you wish to independently determine the trustworthiness of this toolkit, in which case I also recommend a source-code audit and an audit of your development tools.
The source for all imps is provided, though some imps may not be recompileable on some platforms unless you obtain additional classes or headers.
The plain implementations work on any platform. They are trivial Java-only implementations, and do not perform any actual security checks, nor do they grant any real privileges. They are mainly useful for testing, or as examples to work from when writing a new implementation.The Mac OS X implementation relies on Authorization Services. It uses native functions available since 10.0, but testing on 10.0 gave mixed results, so deploying on 10.0 is not advised. The minimum Mac OS X version you should deploy AuthKit on is 10.1. The provided code has been tested under J2SE 1.3.1 and 1.4.1_01 on Mac OS X 10.1 through 10.2.3.
Since the Mac OS X implementation uses Authorization Services, it can interoperate with other programs that use Authorization Services. For example, it can attach to a session using a secret identifier that is the so-called "external form" of an AuthRef. It can likewise supply that form to a process that needs it, such as a helper tool written in C, ObjC, C++, etc. that calls Authorization Services itself.
All Java source is compatible with JDK 1.1 or higher.
These implementations are platform-neutral plain Java. They provide no real authentication or access controls, nor are child processes executed with real elevated privileges.
- glguerin.authkit.imp.plain.DenyAllAuthorization
The DenyAllAuthorization class always denies authorization, throwing an UnauthorizedException or IllegalArgumentException as appropriate. It's main use is as a test to see how well programs you write handle denials. It may also serve as a base-class for writing other testing imps that mainly deny.- glguerin.authkit.imp.plain.GrantAllAuthorization
The GrantAllAuthorization class always grants authorization, never throwing an UnauthorizedException. It may occasionally throw an IllegalArgumentException. It's main use is as a test to see how well programs you write work when all authorization requests are always granted, and no authentication dialog ever appears. It is also useful when a program is being written in parallel with a new Authorization implementation, so the program can be run without having the new impl completed. It may also serve as a base-class for writing other testing imps, such as one based on a Dialog or JDialog.
These implementations are for Mac OS X.JNI-based implementations have a JNI-based native library that must accompany the jar-file. If the JNI library can't be located and loaded, the Java implementation will not work.
- glguerin.authkit.imp.macosx.MacOSXAuthorization
This implementation uses the native Authorization Services API. It uses native functions available since 10.0, but testing on 10.0 gave mixed results, so deploying on 10.0 is not advised. The minimum Mac OS X version you should deploy AuthKit on is 10.1. The provided code has been tested under J2SE 1.3.1 and 1.4.1_01 on Mac OS X 10.1 through 10.2.3.This implementation may work in Cocoa-Java programs. It has not yet been tested there.
KNOWN PROBLEMS UNDER MAC OS 10.0
All the methods work, so you can use AuthKit on 10.0 if you want to.One notable exception is, well, exceptions. The result-codes returned from AuthSvcs are not the ones documented for the actual reason. For example, a user-cancellation returns a different result-code, so UnauthorizedCancellation isn't thrown when it should be. If you can live with things like that, then AuthKit will work on 10.0.
Another thing to consider on 10.0 is the absence of an AuthSvcs policy rule database. There seems to be exactly one policy rule, and it shares credentials and has a 5 minute timeout. Since login produces a credential, one questionable consequence of this single rule is that for 5 minutes after login as an admin user, you don't have to authenticate in order to run a program as root. If the session is detach(true)'ed, and root-execution was overtly authorized, then the shared credential is destroyed. But that's the only way to actually cause a subsequent root-execution to authenticate. In my opinion, this is not good. However, if you can live with things like that, then AuthKit will work on 10.0.
But then you must also consider how 10.0 mounts non-boot disk volumes. Basically, it does the same thing that Disk Copy does with disk-images: the user who mounted the disk appears to own every file on the disk. For a disk-image this makes sense. For a removable disk, this makes some sense. For partitions mounted at startup, though, it makes no sense at all. However, if you can live with things like that, then AuthKit will work on 10.0.
These are just the problems I encountered in my brief testing on 10.0. There may be other problems or peculiarities. If you can live with things like that...
To Greg's Home Page
To Greg's Software Page