Catherine S Green
Republican
Office Manager, High Tek Tube Corp.
Durango High School, Fort Lewis College BA International Business, University of Colorado Denver MA Curriculum and Instruction
80440
None
Attended Republican Meeting March 2020- signed up to be an election judge. Worked as an election judge during the primary June 2020 and the general election November 2020
Board Member of Foxtail Pines Home Owners Association since January 2019.
I say an article in the newspaper looking for volunteers and thought that would be interesting. It’s probably a lot of work without an accolades. My kind of work.
My neighborhood is a mixed neighborhood of full time residents and second homeowners. We have retirees and young families residing here. Two years ago, the Weston Pass fire was very close to us, and we were all concerned that it would impact our neighborhood. Every year during the three summer holidays we have young people riding dirt bikes and atvs in the neighborhood because we share a border with the USFS. That summer we were stopping people and verifying that those vehicles were not fire hazards. This summer at our annual association meeting, the riders were brought up again. Once it was pointed out that our state was just getting out of lockdown and everyone was ready to leave that time behind, the neighbors agreed that letting people have fun outside is a good thing. We had had spring moisture to keep the fire danger low for early summer, and the activity was only for 3 weekends out of the year.
My background is in teaching mathematics. My favorite problem is - show half of eight. There are a lot of answers that are correct. Some answers include 4, 8/2, 2x2, o. You are looking at the o and saying to yourself that is not correct. Think about what the number 8 looks like. Now look at the o, it is the bottom half or the top half of the 8.
Female


Hi, I’m Rafał
Programmer with 5+ years of experience, mainly in ST, Python and C#. Familiarized with JavaScript, Java and C.
Experienced Quality Engineer with practical 6 Sigma and Lean knowledge, used to quick incident/non-conformity response.
Have gained experience in working with suppliers and customers to achieve project goals, as well as in familiarizing myself with various industrial network protocols, Linux system and Docker.
Collaborative team player, quick learner and with good sense of humor.


TIC TAC TOE
Game starts by just Tap on
box
First Player starts as
Player X
And
Second
Player as Player 0
Game starts by just Tap on
box
First Player starts as
Player X
And
Second
Player as Player 0


| magrittr-package {magrittr} | R Documentation |
The magrittr package offers a set of operators which promote semantics that will improve your code by
structuring sequences of data operations left-to-right (as opposed to from the inside and out),
avoiding nested function calls,
minimizing the need for local variables and function definitions, and
making it easy to add steps anywhere in the sequence of operations.
The operators pipe their left-hand side values forward into expressions that
appear on the right-hand side, i.e. one can replace f(x)
with
x %>% f
, where %>%
is the (main) pipe-operator.
Consider the example below. Four operations are performed to arrive at the desired data set, and they are written in a natural order: the same as the order of execution. Also, no temporary variables are needed. If yet another operation is required, it is straight-forward to add to the sequence of operations whereever it may be needed.
For a more detailed introduction see the vignette
(vignette("magrittr")
) or the documentation pages for the
available operators:
%>% | pipe. |
%T>% | tee pipe. |
%<>% | assignment pipe. |
%$% | exposition pipe. |
Maintainer: Lionel Henry<EMAIL_ADDRESS>Authors:
Stefan Milton Bache<EMAIL_ADDRESS>(Original author and creator of magrittr) [copyright holder]
Hadley Wickham<EMAIL_ADDRESS>Other contributors:
RStudio [copyright holder, funder]
Useful links:
Report bugs at https://github.com/tidyverse/magrittr/issues
## Not run: the_data <- read.csv('/path/to/data/file.csv') %>% subset(variable_a > x) %>% transform(variable_c = variable_a/variable_b) %>% head(100) ## End(Not run)


CLUELESS A film review by Janet Miller Copyright 1995 Janet Miller
I took my teenage daughter to a film last night that I really had misgivings about. I had heard that CLUELESS was an okay film but not anything great. Still, Elizabeth wanted to go and mother-daughter bonding and all that.
So, imagine my surprise when I enjoyed the movie as much as she did. Yes, we aren't talking CITIZEN KANE here and there were no explosions that I can remember, but I found CLUELESS a warm and very funny movie.
The heroine, Cher is young, very pretty, and basically a good kid with perhaps a somewhat warped sense of what is important in life, but then again how many teens have their entire act together when they are in high school.
She was usually nice to other people, lectured on not using drugs in school, and was still a virgin since she was saving herself for someone special.
What else I noticed, is that the people in the film were mostly good people. So often in films like this, the parents are dumb and Cher's dad is busy, but he still keeps track of her grades and praises her when she does well. We also see him catch on to a budding romance before either of the two party's do.
A lot has been made of the language of the film as a combination of phony valley talk and "large" words. The language may not reflect real kid speak, but it was cute and wasn't offensive. And anything that encourages kids to improve their vocabulary can't be all bad. Most kids in upper level English classes are being taught vocabulary words that will show up on the SATs so I didn't find Cher's usage strange at all. My daughter has been known to talk like that and she's just starting high school.
Anyway, I thought the movie was fun, my daughter and I had a good time and I would recommend it for teens and parents with a sense of humor.
--
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Visualize Chemkin File: visualize a model by supplying its chemkin file
and RMG-generated species dictionary.
Model Comparison: compare two RMG-generated models by supplying
their individual chemkin files and species dictionaries.
Convert Adjacency Lists: convert adjacency lists in a text file to old-style adjacency lists
which are compatible with RMG-Java.
Merge Models: merge two RMG-generated models by supplying
their individual chemkin files and species dictionaries.
Generate Flux Diagram: generate a flux diagram video by supplying a RMG input file and
completed mechanism, or with a customized set of concentration profiles from a Chemkin job.
Populate Reactions: generate all possible reactions from a set of initial species.
Plot Kinetics: plot forward and reverse kinetics by supplying a list of reactions in chemkin format along with a RMG dictionary.
Create RMG-Java Kinetics Library: create an RMG-Java kinetics library for use as a seed-mechanism or reaction library by supplying a chemkin file along with a RMG dictionary.
Evaluate NASA Polynomial: View enthalpy, entropy, and heat capacity information in human readable format for a CHEMKIN format NASA polynomial.


MISSION: IMPOSSIBLE [Spoilers] A film review by Pete Nelson Copyright 1996 Pete Nelson
Note: There will be some spoilers in here.
I have a few points to make about this movie. First of all, it's not an action movie. About 90% of the good action sequences in the movie you've already seen - in the commercials and the previews. The only major action sequence is the helicopter scene in the tunnel, and that's at the end of the movie. So, if you're looking for a good action movie, save your dough.
Second, the casting is a bit odd too. Ving Rhames (Marsellus Wallace from Pulp Fiction) plays a hacker. While he's not a bad actor, it's very hard to picture big, burly tough-guys as hackers.
Finally, at the end of the movie, I still wasn't sure who the good guys were and who the bad guys were. Either the plot-web was too tangled or I'm just not very good at figuring these things out.
A couple pieces of trivia I saw in the movie: While it's never used, Ethan Hunt's (Tom Cruise) alias is Phillip Douchette. Also, John Voight's character gives away the location of Ethan to the people looking for him. He's going to be on a train. You can see the word "Voit" on the train ticket. May mean something else, but it's an odd coincidence.
To sum up, if you like a good spy-type mystery, you'll probably like this. If you're looking for a great action movie, go see Twister.
Scale: As my friend said when we left, "A five with an occasional eight."
Pete Nelson<EMAIL_ADDRESS><http://www.ecis.com/~weasel>
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


This topic provides an overview of Java packaging and tools.
This topic contains the following sections:
A properly packaged application runs in one or more of the following deployment modes:
As a standalone application, using the system JRE
As a self-contained application, using a private copy of JRE
As a Java Web Start application, using the system JRE
Embedded in a web page, using the system JRE
By default, Java packaging tools produce a package that includes everything needed to provide a good user experience for various user environments, including the following functions:
Ensure that the required JRE is installed.
Automatically download missing dependencies, or offer to install them as needed.
Provide visual feedback to the user while the application is loaded.
Show descriptive error messages.
Java application packages work in the following execution environments without requiring modifications:
Launch from the command line using the Java launcher.
Double-click the JAR file.
Double-click the self-contained application launcher.
Embed the application in a web page.
Optionally, Java packaging tools can produce self-contained application packages that simplify redistribution by avoiding dependencies on external software. For more information about self-contained application packages, see Chapter 7, "Self-Contained Application Packaging."
The Java application package that is generated by default includes the following items:
Executable application JAR file, which contains application code and resources and can be launched by double-clicking the file
Additional application JAR and resource files
Deployment descriptor for web deployment, which is kept in the JNLP file
HTML file that contains sample JavaScript code to embed and launch Java content from a web page
Figure 5-1 shows an example of the structure of a base JavaFX application package. By default, NetBeans IDE also includes a copy of other support files in the web-files
folder. However, for production, using a public copy of the dtjava.js
file is recommended because the public versions is always up to date.
Figure 5-1 Example of a Package for Web Deployment
The Java Packager tool added several steps to the build process, which simplify the packaging of your Java applications. These steps are shown in Figure 5-2.
Figure 5-2 The Build Process for Applications
The additional steps in the process are marked with colored arrows:
(Optional, JavaFX only) Convert style sheets to binary form.
Converts CSS files to binary form to reduce parsing overhead at application runtime.
Create JAR
Packages code and resources needed for the JavaFX application into a JAR file and embeds the preloader JAR, if requested.
See Section 5.5, "Create the Main Application JAR File."
For Java applications, the jar
command is recommended for creating your JAR file, instead of the Java Packager.
Sign the JAR files
Signing JAR files is required if your application is embedded in a web page or is launched from a browser.
Signs the JAR files using a different method than the jarsigner
tool. This method reduces the JAR size overhead for signing, which improves the download time.
Run the Deploy task
Assembles the application package for distribution. By default, the deploy task generates the base application package, but it can also generate self-contained application packages, if requested. See Section 5.7, "Run the Deploy Task or Command" and Chapter 7, "Self-Contained Application Packaging."
The recommended way to package Java applications is to use a collection of Ant tasks (ant-javafx.jar
), which are provided with the JRE.
NetBeans IDE uses these Ant tasks to package JavaFX and Java SE projects. Embedded packaging support in NetBeans IDE covers most of the typical use cases. However, if you need something special, you can tune packaging by adding custom packaging hooks to the build.xml
file, for example, as a -post-jar
target.
Most of the other popular IDEs can easily use custom Ant build scripts. Other popular build frameworks, for example Maven or Gradle, support integration with Ant also.
The JRE includes a command-line packaging utility, javapackager
, which can be used for simple packaging tasks. Note that javapackager
is a convenience utility and does not provide as much flexibility or as many options as Ant tasks.
Table 5-1 summarizes how to accomplish the build steps using the various packaging tools available. Note that javapackager
also provides a -makeall
macro command to create a complete application package for simple applications. For more information, see Chapter 9, "The Java Packager Tool."
Table 5-1 Java Packaging Tasks and Tools
| Task | Java Packager Library Ant Task | Java Packager Tool Command | NetBeans IDE |
|---|---|---|---|
|
Convert any CSS files to binary format (See Section 5.4, "Style Sheet Conversion.") |
|
javapackager -createbss |
Packaging category in Project Properties
|
|
Create a JAR archive (See Section 5.5, "Create the Main Application JAR File.") |
|
javapackager -createjar |
Occurs by default with a Build command, using the configuration in Project Properties. |
|
Sign a JAR archive as one binary object (See Section 5.6, "Sign the JAR Files.") |
|
javapackager -signJar |
Deployment category in Project Properties
|
|
Assemble application package for deployment (See Section 5.7, "Run the Deploy Task or Command") and Chapter 7, "Self-Contained Application Packaging." |
|
javapackager -deploy |
Base application package is produced by default with a Build command. To produce self-contained applications, see Section 7.3.2, "Basic Build." |
Converting style sheets to binary format is optional, but improves application performance. This is especially noticeable on larger CSS files.
To use a binary CSS file, refer to the binary file instead of the CSS file in your code, as shown in Example 5-1:
Example 5-1 Using a Binary Stylesheet
scene.getStylesheets().add(this.getClass().getResource ("mystyles.bss").toExternalForm());
The following methods are available for converting style sheets to binary:
Ant task: See Convert CSS Files to Binary
Java Packager tool: See the -createbss
command in the javapackager
reference for Windows or Solaris, Linux, and OS X.
NetBeans IDE: Convert the style sheet by selecting Binary Encode JavaFX CSS Files in the Packaging category of Project Properties.
In addition to application classes and resources, you can provide the following information when you create the main application JAR file:
Platform requirements
Required version of the JRE
Required Java VM arguments
The following details about the application:
Name of the main application class (Required)
Name of the JavaFX preloader class, if a preloader is provided
Details about application resources, if applicable
Set of class files and other resources included in the JAR file
List of auxiliary JAR files needed by the application, including a custom JavaFX preloader JAR file, if needed
The use of Java packaging tools to create the main application JAR file is very important for packaging JAR files and self-contained applications that can be started with a double-click. The main application JAR file includes a launcher program that takes care of the bootstrap launch, which improves launch by performing the following tasks:
Checks for the JRE
Guides the user through any necessary installations
Sets the system proxy for your application
|
Note: If you have a JavaFX preloader, as shown in Figure 5-2, create a separate JAR file with the preloader resources, using any of the packaging methods described. For more information, see Chapter 13, "Preloaders for JavaFX Applications." |
The following methods are available for creating the main application JAR file:
Ant task: See <fx:jar> Usage Examples.
Java Packager tool: See the -createjar
command in the javapackager
reference for Windows or Solaris, Linux, and OS X.
NetBeans IDE: Automatically creates the JAR file when you specify this information in the project's properties.
To use traditional methods to sign JAR files, see the steps for code signing in the Java Tutorial, and the description of the standard Ant signjar
task for information. The traditional method is recommended for Java applications.
Java packaging tools provide an alternative signing method that helps to reduce the size overhead of signing the JAR file. Using this method, you sign the JAR file as one large object instead of signing every JAR entry individually. This method can save up to 10 percent of the total JAR size.
To use the alternative signing method, you need the keystore and signing key. See the Java Tutorial on generating keys for instructions.
The following methods are available for signing the JAR files:
Ant task: See <fx:jar> Usage Examples
Java Packager tool: See the -signJar
command in the javapackager
reference for Windows or Solaris, Linux, and OS X.
NetBeans IDE: Enable signing by selecting the Request unrestricted access check box in the project properties. To sign with a specific certificate, click Edit next to the check box.
|
Note: All JAR files must be signed or unsigned in the context of a single deployment descriptor file. If you need to mix signed and unsigned JAR files, use an additional Ant task to generate an additional deployment descriptor for each JAR file. These additional deployment descriptors are called extension descriptors. Use <fx:resources> to refer to the extension descriptors when the main descriptor is generated. For an example of how to do this, see Using <fx:resources> for Extension Descriptors. |
A basic distribution package consists of the following items:
The main executable JAR file
(Optional) A set of auxiliary JAR files, including a JAR file with JavaFX preloader code
A deployment descriptor, defining how to deploy the application
Either a basic HTML file with sample code to embed the application into your own web page, or a custom web page that is the result of preprocessing an HTML template
Java packaging tools can also package the application as a self-contained application bundle. This option is disabled by default. For more information, see Chapter 7, "Self-Contained Application Packaging."
To assemble the distributable package, use one of the following methods:
Ant task: See <fx:deploy> Task Usage Examples.
Java Packager tool: See the -deploy
command in the javapackager
reference for Windows or Solaris, Linux, and OS X.
NetBeans IDE: Creates a distributable package every time the project is built. Packaging options are set in the project's properties.
The key part of this task is providing information to fill the deployment descriptor for web deployment. The following information is needed:
Entry points: the main application class, JavaFX preloader class, and other details
Defined as attributes of the <fx:application> tag.
Parameters to be passed to the application
Defined using <fx:param> and <fx:htmlParam> tags under <fx:application>.
The preferred application stage size
It is crucial to reserve the display area for embedded content.
Width and height are defined using width and height attributes in the <fx:deploy> tag for Ant tasks, the javapackager -deploy
command in the javapackager
tool for Windows or Solaris, Linux, and OS X, or in the Run category of NetBeans project properties.
A description of the application to be used in dialog boxes that the user sees during application startup
Defined using the <fx:info> tag.
Platform requirements, including the required version of the JRE and JVM settings
Defined using the <fx:platform>tag. For an example, see <fx:platform> Parameter to Specify JVM Options.
Desktop integration preferences of the application, such as adding a shortcut to the desktop or a reference to the Start menu.
Defined using the optional <fx:preferences> tag. See <fx:preferences> Usage Examples.
Permissions needed to run the application.
By default, web applications run in the sandbox. To request elevated permissions, use the <fx:permissions> tag.
The following types of resource files are supported:
JAR files
Native JAR files
JNLP files
Icons
License files
Data files
Every resource has additional metadata associated with it, such as operating system and architecture for which this resource is applicable, plus a priority preference defining the point in the application life cycle at which this resource is needed. Careful use of metadata can have a significant impact on the application startup experience. For a list of supported values, see Table 10-10.
All files in the resource set are copied to the build output folder. However, not all of the files are used in all execution modes, as described in the following paragraphs.
Regardless of execution mode, all regular JAR files from the resource set are added to the application class path.
Native JAR files and JNLP files are used only for web deployment. Additional JNLP files are typically used to refer to external JNLP extensions, or if the application itself is packaged as a set of components. See Using <fx:resources> for Extension Descriptorsin the JavaFX Ant Task Reference.
Native JAR files are used to deploy native libraries used by application. Each native JAR file can contain a set of native dynamic libraries and is inherently platform-specific. For more details, see Example 5-11 and Section 5.8.3, "Packaging Complex Applications."
License files are currently applicable to self-contained applications only, and are used to add a click-through license to installable packages. See Section 7.4, "Installable Packages."
Data files do not have special semantics, and applications are free to use them for anything. For example, if your application needs to bundle a movie file, then you can mark it as "data," and it is included in the application package.
For further details, see Table 10-10.
The Deployment Toolkit provides a set of hooks that you can use to customize the startup behavior when an application is deployed in the browser. Developers must install a callback function to the hook, so the hook is utilized by the Deployment Toolkit.
Chapter 19, "Deployment in the Browser" describes in detail what hooks are available and how to use them in the code. However, to ensure that the hooks are correctly installed, they also must be specified at packaging time.
To specify callbacks, list them in the <fx:callbacks> tag under <fx:deploy>. Add an <fx:callback> entry for every callback that you want to install, and specify the name of the hook in the name
attribute. The content of the <fx:callback> tag is the JavaScript function to be used. You can use a full function definition, or refer to a function defined elsewhere.
The following methods are available for packaging custom JavaScript actions:
Ant task: See <fx:jar> Usage Examples.
Java Packager tool: See the -deploy
command in the javapackager
reference for Windows or Solaris, Linux, and OS X.
NetBeans IDE: Add callbacks in the Deployment category of Project Properties. Click the Edit button to the right of Custom JavaScript Actions.
By default, Java packaging tools generate a simple web page with a placeholder for the embedded application. You can manually copy code from this generated page to your web page, but this is error prone and time consuming if you need to do this often.
Java packaging tools also support injecting required code into an existing web page through the use of an input template. This technique is especially useful when the application is tightly integrated with the web page, for example if the application uses JavaScript to communicate with the web page, or if callbacks are used and their code is kept in the web page itself.
An input template is an HTML file containing markers to be replaced with JavaScript or HTML code needed to deploy the application on the web page. Example 5-2 shows an example of an input template for a JavaFX application.
Example 5-2 HTML Input Template
  <title>Host page for JavaFX Application</title> #DT.SCRIPT.CODE# #DT.EMBED.CODE.ONLOAD#
Embed JavaFX application into existing page

#DT.SCRIPT.CODE#
and #DT.EMBED.CODE.ONLOAD#
are markers that are substituted with JavaScript and HTML code when the template is processed. Markers have the form of #
MARKERNAME#
or #
MARKERNAME(
id)#
, where id is the identifier of an application (specified using the id
attribute of the <fx:deploy> tag if you are using Ant), and MARKERNAME is the type of the marker. If id is not specified, then MARKER matches any application. For a list of supported markers, see <fx:template> in the Ant task reference.
Templates can be used to deploy multiple applications in the same page. Use the full form of the marker including application ID (an alphanumeric string without spaces), and pass the partially processed template file when packaging each application to insert.
Example 5-3 shows an example of a template that is used to deploy multiple applications.
Example 5-3 An Input Template Used to Deploy Multiple Applications
  <title>Page with two application</title>
Multiple applications in the same page
 JavaFX app:

 Another app:

Example 5-3 demonstrate one useful feature of the template processor, which is that the markers can be placed in the HTML comments. If the comment does not contain anything other than marker code, then the comment tags are removed from the content in the resulting HTML. This feature keeps the HTML in the template page well formed.
The following methods are available for using templates:
Ant task: Add a template tag. See <fx:jar> Usage Examples.
Java Packager tool: See the -deploy
command in the javapackager
reference for Windows or Solaris, Linux, and OS X.
NetBeans IDE: Specify the input HTML template file in the Run category of Project Properties.
This section presents several examples for typical deployment tasks.
The examples use Ant APIs, but in most cases the same result can be achieved using the Java Packager tool. See Chapter 10, "JavaFX Ant Tasks" and Chapter 9, "The Java Packager Tool."
Java and JavaFX applications support two types of application parameters: named and unnamed (see the API for Application.Parameters).
Static named parameters can be added to the application package using <fx:param> and unnamed parameters can be added using <fx:argument>. They are applicable to all execution modes, including standalone applications.
Parameters can also be passed to Java and JavaFX applications from the web page that hosts the application using <fx:htmlParam>. <fx:htmlParam>
is applicable to both embedded applications and Java Web Start applications.
Passing parameters from the HTML page is most useful if the parameters are dynamic. To use this technique, the following approach is recommended:
Use a web page template (see Section 5.7.4, "Web Page Templates") to provide JavaScript code to prepare dynamic parameters.
Pass JavaScript code as a value for <fx:htmlParam>
, and specify escape="false"
. The code is evaluated at runtime
Example 5-4 shows the use of various parameter types:
Example 5-4 Using Various Parameter Types
<fx:application name="Test" mainClass="tests.Params">  <fx:argument>Arg1</fx:argument> <fx:argument>Arg2 with spaces </fx:argument>  <param name="sampleParam" value="Built with ${java.version}"/> <param name="noValueParam"/>  <htmlParam name="staticParamFromWebPage" value="(new Date()).getTime()"/> <htmlParam name="dynamicParamFromWebPage" escape="false" value="(new Date()).getTime()"/> </fx:application>
Does your application need a larger heap size? Do you want to tune garbage collector behavior, or trace class loading?
You can specify the required JVM options and set system properties using the <fx:jvmarg> and <fx:property>
tags in your Ant task. These tags are applicable to all execution modes except standalone applications. You always get the default JVM if you double-click the JAR file, but you can tailor the JVM to your requirements if you are running a self-contained application, a Java Web Start application, or an application embedded into a web page.
If you use any non-secure JVM options or system properties, the application must have elevated permissions. A set of secure JVM command-line arguments and system properties is defined in the Java Web Start Developers' Guide.
In Example 5-5, the Ant task packages the application so that when the application is run, the JVM is launched with the following arguments:
-Xmx400 -verbose:jni -Dpurpose=sample
Neither -verbose:jni
nor purpose
are secure, so elevated permissions are required for Java Web Start and embedded execution modes.
Example 5-5 Specifying Custom JVM Options and Properties in the Ant Task
<fx:platform javafx="2.1+"> <fx:jvmarg value="-Xmx400m"/> <fx:jvmarg value="-verbose:jni"/> <fx:property name="purpose" value="sample"/> </fx:platform>
If you require the capability to specify JVM options that a user can override, use the <fx:jvmuserarg>
attribute in <fx:platform>
, or for self-contained applications, use the -BuserJvmOptions
attribute for the Java Packager tool. These attributes explicitly define an attribute that can be overridden by the user.
Example 5-6 Specifying Options that Users Can Override in an Ant Task
<fx:platform> <fx:jvmuserarg name="-Xmx" value="768m" /> <fx:jvmuserarg name="-Xms" value="128m" /> </fx:platform>
If you are using the Java Packager tool to package a self-contained application, include the following attributes:
-BuserJvmOptions=-Xmx=768m -BuserJvmOptions=-Xms=128m
In the examples, -Xmx768m
is passed as a default value for heap size, and -Xms128m
is passed as the default value for the initial heap size. The user can override these values in a user configuration file on Linux and OS X, or in the registry on Windows. The configuration file and the registry use the conventions of the Java Preferences API for location and format. Self-contained applications can use the UserJvmOptionsService
API to enable users to set JVM options in the application. See Chapter 15, "Customizing JVM Options in Self-Contained Applications" for information about this API.
The node for the applications user preferences is based on the application ID, which is passed as -Dapp.preferences.id
to the Application so it can provide a preferences UI, if required. If the preferences ID is not passed, the fully qualified main class name is used. The application can access the JVM user options with node -Dapp.preferences.id
and key JVMOptions
.
The following examples provide code for overriding the JVM heap size value of 768m to 400m on different platforms.
Example 5-7 Overriding Default Value on OS X
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>JVMUserOptions</key> <dict> <key>-Xmx</key> <string>400m</string> </dict> </dict> </plist>
You can provide string substitution to the root of the install directory for parameters passed into the application. In particular, you can use the macro $APPDIR
, which is the full path of the directory that contains the self-contained bundles that the bundler creates. In the following example, if the program is installed in C:\Program Files\myexample
, then the macro $APPDIR
expands to C:\Program Files\myexample\app
(because the app
directory is where the application resources are installed in this example).
Real-life applications often have more than just a single JAR artifact. They may have third-party libraries, data files, native code, and so on. For a complex application, you might need special packaging tweaks to support different execution modes.
The following suggestions are general guidelines for packaging complex applications:
Mark platform-specific resources accordingly.
For JAR file that a user can double-click, consider packaging everything into a single JAR file and loading native libraries and data files from inside that JAR file.
Alternatively, if you prefer to have multiple files:
Ensure that all dependent JAR files are listed in the <fx:resources>
tag in the <fx:jar>
task that creates the main JAR file.
List all data files and libraries in filesets with type="data"
to copy them into the output folder.
Load native libraries and resources from locations relative to the main JAR file.
See the example <fx:jar> Ant Task for a Simple Application in the Ant Task Reference chapter.
The following guidelines are for self-contained applications:
Avoid packaging anything but the main JAR file using <fx:jar>
.
List all dependent JAR files in the <fx:resources>
section of <fx:deploy>
and <fx:jar>
for the main application JAR file.
Either use an explicit location relative to the application JAR file to load native libraries, or copy native libraries into the root application folder. Use type="data"
to copy native library files.
See Example 7-4.
The following guidelines are for Java Web Start and embedded applications:
List all dependent JAR files in the <fx:resources>
section of <fx:deploy>
.
Wrap native libraries into the JAR files for distribution.
Use one JAR file per platform. Ensure that the JAR files contain only native libraries and that the libraries are all in the top-level folder of the JAR file.
See Example 5-11.
Example 5-11 Packaging Native Libraries into JAR Files
<jar destfile="${basedir}/build/native-libs-win-x86.jar" basedir="native/windows/x86" includes="*"/> <jar destfile="${basedir}/build/native-libs-win-x86_64.jar" basedir="native/windows/x86_64" includes="*"/> ....  <signjar keystore="test.keystore" alias="TestAlias" storepass="xyz123"> <fx:fileset dir="dist" includes="**/*.jar"/> </signjar>  <fx:deploy width="600" height="400" outdir="${basedir}/${bundle.outdir}" outfile="Demo"> <fx:info title="Demo app"/> <fx:application name="${bundle.name}" mainClass="${javafx.main.class}"/> <fx:permissions elevated="true"/> <fx:resources>  <fx:fileset dir="dist" includes="*.jar"/> <fx:fileset dir="dist" includes="lib/*.jar"/>  <fx:fileset dir="build" type="native" os="windows" arch="x86"> includes="native-libs-win-x86.jar"/> </fx:fileset> <fx:fileset dir="build" type="native" os="windows" arch="x64" includes="native-libs-win-x86_64.jar"/> </fx:fileset> ... </fx:resources> </fx:deploy>
To size embedded applications relative to the size of browser window, use the embeddedWidth
and embeddedHeight
attributes in the <fx:deploy>
task. These optional attributes are used only for embedded applications, and only in the generated HTML and Javascript code. Also note that width
and height
values in pixels are still required.
To fill the browser window completely, set embeddedWidth
and embeddedHeight
to "100%"
. This alone does not produce a perfect result, because scroll bars are added to the browser window for the following reasons:
The default HTML template has some other content.
The default style of HTML tags might reserve space for things like margins.
The resulting web page appears to be larger than the view area, and therefore the browser adds scroll bars.
The full solution consists of the following steps:
Specify embeddedWidth="100%"
and embeddedHeight="100%"
in the <fx:deploy>
task. (See Example 5-12.)
Add a custom web page template. (See Example 5-13 and Section 5.7.4, "Web Page Templates.")
Reset the style of used HTML elements to ensure that the application is the only element in the view area.
Example 5-12 Packaging
<fx:deploy width="100" height="100" embeddedWidth="100%" embeddedHeight="100%" outdir="${basedir}/${dist.dir}" outfile="${application.title}"> <fx:application name="${application.title}" mainClass="${javafx.main.class}"/> <fx:template file="${basedir}/web/index_template.html" tofile="${dist.dir}/TestApp.html"/> <fx:resources> <fx:fileset dir="${basedir}/${dist.dir}" includes="*.jar"/> </fx:resources> <fx:info title="${application.title}" vendor="${application.vendor}"/> </fx:deploy>
Example 5-13 Web Page Template (web/index_template.html)

Several options are available for improving application launch time for the first and subsequent launches of web applications.
|
Tip: While you are developing an application, you can disable optimizations to avoid unneeded complexity. Use optimizations at the final packaging stage. |
Every time a web application starts, both Java Web Start and embedded, a background update check is conducted for to determine if updates are required. By default, Java and JavaFX applications perform "lazy" update checks in the background while the application runs. This helps to avoid wait time to check for updates when the application starts. If updates are found, then the updates are used only after the application restarts. To switch between update modes, use the following methods in the Java packaging tools:
Ant task: See the updatemode
attribute of the <fx:deploy> task.
Java Packager tool: See the -updatemode
option of the javapackager -deploy
command in the javapackager
tool for Windows or Solaris, Linux, and OS X.
NetBeans IDE: Select Check for Application Updates in Background, In the Deployment category of Project Properties.
You can embed the content of the deployment descriptor into the HTML page, which helps to reduce the number of network connections needed to launch the application, as shown in Figure 5-3.
Figure 5-3 Embedding JNLP Content Reduces Network Connections
The original JNLP file is loaded in the background to perform application update checks.
The following methods are available for embedding the content of the deployment descriptor:
Ant task: See the embedjnlp
attribute of the <fx:deploy> task.
Java Packager tool: See the -embedjnlp
option of the javapackager -deploy
command in the javapackager
tool for Windows or Solaris, Linux, and OS X.
NetBeans IDE: The content is embedded by default.
If the application is signed, then this option embeds into the JNLP file a copy of the details of the certificate used to sign the JAR files. If the user needs to approve permissions, this certificate, followed by a security prompt, is shown while the application JAR files are being loaded, as shown in Figure 5-4.
Figure 5-4 Advantage of Embedding the Certificate in the Deployment Descriptor
The following methods are available for embedding the signing certificate into the deployment descriptor:
Ant task: See the cachecertificates
attribute of the <fx:permissions> task.
Java Packager tool: See the -embedCertificates
option of the javapackager -deploy
command in the javapackager
tool for Windows or Solaris, Linux, and OS X.
Reducing the JAR file size helps to reduce download time and improve startup time. See Section 5.6, "Sign the JAR Files."


by Curtis Edmonds --<EMAIL_ADDRESS>To quote Johnny Caspar, it's all about ethics. If you're an ethical movie reviewer, you don't give away secrets about movies, you don't spoil the plot for others, you don't say grandly effusive things about wretched movies. (If you're an unethical movie reviewer, of course, you get to see your name plastered on newspaper advertisements.) If you can't trust your friendly neighborhood movie reviewer, who can you trust? Otherwise, "then you're back with anarchy, right back in the jungle."
So, no, I won't tell you the secret of The Sixth Sense, even though I would like to. I will tell you that I figured it out early on, and that I think you'll enjoy the movie a lot more if you don't try to figure it out for yourself. The real question about The Sixth Sense is not about the secret, not really, but about whether the movie is worth seeing if you know the secret. Three of the best secretive movies of recent years -- The Usual Suspects, Seven, and The Crying Game -- still hold up after repeated viewings, mostly on the strength of the performances and the script. On the other hand, once Michael Douglas's The Game ends, there isn't much point in going back to the rental counter for another look. The quality of the movie is more important than the quality of the secret.
The Sixth Sense is a quality movie because of the quality performances of Bruce Willis and young Haley Joel Osment. Willis plays a Philadelphia child psychologist, dedicated to his work. The dedication is tested when a former patient breaks into his house and shoots him before committing suicide. A year later, Willis finds young Cole Sear (Osment), exhibiting some of the same symptoms as his previous patient.
Apart from an early scene where Willis engages in some Dr. Seuss-style banter (reminiscient of his old David Addison role on Moonlighting) with Olivia Williams, Willis operates through the movie in Sincere Mode. The beautifully counterpointed script has him doing one of two things: he's either in session with Cole, or trying to make up with Williams (Rushmore), who has been depressed and distant ever since the shooting. Willis in Sincere Mode is usually a bad sign -- The Jackal springs to mind -- but, fortunately, Sincere Mode in The Sixth Sense contains a lot of vulnerability that leads us to some very poignant scenes.
Most of those scenes are with Osment, an 11-year-old actor who's getting rave reviews for his performance, not to mention the early lead in the Best Supporting Actor race. (He's in Sincere Mode too -- in fact, the whole movie is so sincere it should be expecting a visit from the Great Pumpkin.) Osment has to convince us about halfway through the movie that he "sees dead people" -- a tough job, considering that we haven't seen any of the dead people he sees, not to speak of, anyway. But, of course, we believe him, because we've seen him stopped, time and again, by some nameless fear that we can't see. Later, we get to see a lot more of these ghosts and understand what is scaring Osment so badly, but his performance does an excellent job of conveying the unseen terrors that make the movie work.
How good is Osment?  I would, however, like to take this opportunity to mention (in case Osment's agent is reading this) that there's a book out there by Orson Scott Card called Lost Boys that I've always wanted to see be made into a movie, and that requires a young child to play a character who may be in touch with the supernatural. (I still think that Jake Lloyd is a better fit for Ender's Game, another Card novel that requires a young protagonist.)
Add to these two great performances a great job of writing and directing (and acting, in a brief scene) by M. Night Shyamalan, the atmospheric look of Philadelphia in fall, and good supporting work by Olivia Williams and Toni Colette, and you've got a very good movie, one that's worth seeing again, even if you know the secret.
Grade: A-
-- Curtis D. Edmonds<EMAIL_ADDRESS>Movie Reviews: http://us.imdb.com/M/reviews_by?Curtis+Edmonds
"So how does a conservative movie reviewer, who doesn't want to spoil the movie, write a review? The same way he takes the lamb chop from rottweiller -- carefully. Another way is to fill two-thirds of the column with irrelevant woolgathering about other topics so that you only have room for a paragraph for the real review." -- Jonah Goldberg
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Students decide to become a dentis at different point of their lives. Some want to become dentists when they are just 5 years old, while others do not make the decision until getting into the college. However, no matter when do you make that decision, you want to make sure you like this profession. That is why shadowing dentists is an important part of the dental school application
Dental schools like to see applicants with shadowing experience, as it shows that the student has a solid understanding of what is involved in the practice of dentistry.Shadowing enables students to observe first-hand the vital role confidentiality plays in building and maintaining trust with a patient. Shadowing will also give you the chance to confirm your descion of becoming a dentist.
| Patient number | Dental issues | Treatment | note | 1 | tooth 12 has cares | Remove the corrsion, apply acid etching, rinse with water, apply primer.... | Patient has high blood pressure |
|---|
The hours varies based the school. Most applicants have at least 100 shadowing hours. You could distribute your shadowing hour between serveral different dentists. You could check the newest shadowing hour requirements from all dental school HERE.


You can specify a delay to debounce the input event, a case scenario that you may want to wait for the user to stop typing then validate the field.
This can be achieved by adding a data-delay
attribute on the field being validated, and assign it the number of milliseconds you want to wait for.
After validating a file, you may want to reject the uploaded file if it fails the validation, this can be done by adding
the reject
modifier to directive. so you would use it like this: v-validate.reject
.
reject
modifier is only relevant on file inputs, adding it to other input types will not have an effect.
The basic approach relies on listening to the input
or the change
events depending on the file type.
However most of the time, your values are bound to your Vue instance and some code may change their inputs programatically, the basic approach won't detect this change.
The Solution: The v-validate
directive can take a binding expression, the expression is the data name you wish to validte. for example:
name
attribute, as the expression name will be used instead.
email
field was immediatly validated when you open the page, you may not want this behavior, use the initial
modifier to tell the validator to ignore the first evaluation like this: v-validate.initial
.
delay
attribute and reject
modifier won't have an effect anymore. so you might want to handle debouncing the inputs yourself.
You may want to trigger all inputs validation before submitting a form, maybe display an alert or prevent form submission if any errors are detected.
You may want to display error messages in different languages, here is an example on how you may do that. The language below is Arabic (RTL):
data-as
attribute which tells the validator to use that value as the field name when generating error messages, this is a good way to display 'pretty names' for your inputs in error messages, which would make sense when displaying messages in other languages.


Page 1 of 1
What Program?
Posted:
Sat Sep 01, 2007 4:06 am
by daekighn
What Program do u guys use to make Project Volucris?
Posted:
Sat Sep 01, 2007 10:31 am
by 9sam1
i believe there making there own engine from scratch correct?
Posted:
Sat Sep 01, 2007 1:42 pm
by thadiusofx3
I'm not sure what your question means.
What program are we using to make the models, sounds, or content?
or What programming language are we using to code the game?
Posted:
Sat Sep 01, 2007 2:21 pm
by 9sam1
i think he thinks your using some kind of program to make this game, like rpgmaker is used to make games and poo and i guess he thinks you guys use some sort of mmorpg making program.
Posted:
Sat Sep 01, 2007 4:52 pm
by Himora
Notepad I imagine
Posted:
Sun Sep 02, 2007 8:51 am
by Karl G.
My tools:
Microsoft Visual C++ 2005 Express Edition
DirectX SDK
Ogg-Vorbis Library
WinSock 2.0
Posted:
Sun Sep 02, 2007 5:08 pm
by thadiusofx3
For the media I'm using
Blender:
http://www.blender.org
MakeHuman:
http://www.dedalo-3d.com/
Audacity:
http://www.audacity.com
guitar pro 5:
http://www.guitar-pro.com
texture maker: dunno link right now


About
We believe access to the spoken word gives us a unique glimpse into the historic,
political and cultural history of the world we share.
Further, we believe that inherent in
these quotations lies the essence of the individuals we have quoted; their interests,
belief system, comments and ideas are captured in time to benefit our generation and the next.


WITNESS LIST State Recreational Resources Committee (Subcommittee on State Parks) May 2, 2000-2:00P State Parks For: Pressler, Larry (Texas Recreation and Park Society) On: Heleman, John (Texas Comptroller of Public Accounts) Sansom, Andrew (Texas Parks and Wildlife Department)


A significant enhancement to the Java security architecture is the capability to achieve single sign-on using Kerberos Version 5 in the next release of Java Standard Edition (J2SE). A single sign-on solution lets users authenticate themselves just once to access information on any of several systems. This is done using JAAS for authentication and authorization and Java GSS-API to establish a secure context for communication with a peer application. Our focus is on Kerberos V5 as the underlying security mechanism for single sign-on, although other security mechanisms may be added in the future.
With the increasing use of distributed systems users need to access resources that are often remote. Traditionally users have had to sign-on to multiple systems, each of which may involve different usernames and authentication techniques. In contrast, with single sign-on, the user needs to authenticate only once and the authenticated identity is securely carried across the network to access resources on behalf of the user.
In this paper we discuss how to use single sign-on based on the Kerberos V5 protocol. We use the Java Authentication and Authorization Service (JAAS) to authenticate a principal to Kerberos and obtain credentials that prove its identity. We show how Sun's implementation of a Kerberos login module can be made to read credentials from an existing cache on platforms that contain native Kerberos support. We then use the Java Generic Security Service API (Java GSS-API) to authenticate to a remote peer using the previously obtained Kerberos credentials. We also show how to delegate Kerberos credentials for single sign-on in a multi-tier environment.
Kerberos V5 is a trusted third party network authentication protocol designed to provide strong authentication using secret key cryptography. When using Kerberos V5, the user's password is never sent across the network, not even in encrypted form, except during Kerberos V5 administration. Kerberos was developed in the mid-1980's as part of MIT's Project Athena. A full description of the Kerberos V5 protocol is beyond the scope of this paper. For more information on the Kerberos V5 protocol please refer to [1] and [2]
Kerberos V5 is a mature protocol and has been widely deployed. It is available on Solaris as SEAM and on Windows 2000 and several other platforms. A free reference implementation in C is available from MIT. For these reasons we have selected Kerberos V5 as the underlying technology for single sign-on in J2SE.
Until recently the Java 2 security architecture solely determined privileges by the origin of the code and the public key certificates matching the code signers. However, in a multi-user environment it is desirable to further specify privileges based on the authenticated identity of the user running the code.
JAAS supplies such a capability. JAAS is a pluggable framework and programming interface specifically targeted for authentication and access control based on the authenticated identities.
The JAAS framework can be divided into two components: an authentication component and an authorization component.
The JAAS authentication component provides the ability to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet.
The JAAS authorization component supplements the existing Java security framework by providing the means to restrict the executing Java code from performing sensitive tasks, depending on its codesource and depending on who is executing the code.
JAAS authentication framework is based on Pluggable Authentication Module (PAM)[3, 4]. JAAS authentication is performed in a pluggable fashion allowing system administrators to add appropriate authentication modules. This permits Java applications to remain independent of underlying authentication technologies, and new or updated authentication technologies can be seamlessly configured without requiring modifications to the application itself.
JAAS authentication framework also supports the stacking of authentication modules. Multiple modules can be specified and they are invoked by the JAAS framework in the order they were specified. The success of the overall authentication depends on the results of the individual authentication modules.
JAAS uses the term Subject to refer to any entity that is the source of a request to access resources. A Subject may be a user or a service. Since an entity may have many names or principals JAAS uses Subject as an extra layer of abstraction that handles multiple names per entity.Thus a Subject is comprised of a set of principals. There are no restrictions on principal names.
A Subject is only populated with authenticated principals. Authentication typically involves the user providing proof of identity, such as a password.
A Subject may also have security related attributes, which are referred to as credentials. The credentials can be public or private. Sensitive credentials such as private cryptographic keys are stored in the private credentials set of the Subject.
The Subject class has methods to retrieve the principals, public credentials and private credentials associated with it.
Please note that different permissions may be required for operations on these classes. For example AuthPermission("modifyPrincipals") may be required to modify the principal set of the Subject. Similar permissions are required to modify the public credentials, private credentials and to get the current Subject.
Java 2 enforces runtime access controls via java.lang.SecurityManager. The SecurityManager is consulted anytime sensitive operations are attempted. The SecurityManager delegates this responsibility to java.security.AccessController. The AccessController obtains a current image of the AccessControlContext and verifies that it has sufficient permission to do the operation requested.
JAAS provides two methods doAs and doAsPrivileged that can be used to associate an authenticated Subject with the AccessControlContext dynamically.
The doAs method associates the Subject with the current thread's access control context and subsequent access control checks are made on the basis of the code being executed and the Subject executing it.
public static Object doAs(final Subject subject, final PrivilegedAction action) public static Object doAs(final Subject subject, final PrivilegedExceptionAction action) throws PrivilegedActionException;
Both forms of the doAs method first associate the specified subject with the current Thread's AccessControlContext, and then execute the action. This achieves the effect of having the action run as the Subject. The first method can throw runtime exceptions but normal execution has it returning an Object from the run() method of its action argument. The second method behaves similarly except that it can throw a checked PrivilegedActionException from its run() method. An AuthPermission("doAs") is required to call the doAs methods.
The following methods also execute code as a particular Subject:
public static Object doAsPrivileged(final Subject subject, final PrivilegedAction action, final AccessControlContext acc); public static Object doAsPrivileged(final Subject subject, final PrivilegedExceptionAction action, final AccessControlContext acc) throws PrivilegedActionException;
The doAsPrivileged method behaves exactly as doAs, except that it allows the caller to specify an access control context. Thus it effectively throws away the current AccessControlContext and authorization decisions will be based on the AccessControlContext passed in.
Since the AccessControlContext is set on a per thread basis, different threads within the JVM can assume different identities. The Subject associated with a specific AccessControlContext can be retrieved by using the following method:
public static Subject getSubject(final AccessControlContext acc);
The LoginContext class provides the basic methods used to authenticate Subjects. It also allows an application to be independent of the underlying authentication technologies. The LoginContext consults a configuration that determines the authentication services or LoginModules configured for a particular application. If the application does not have a specific entry, it defaults to the entry identified as "other".
To support the stackable nature of LoginModules, LoginContext performs authentication in two phases. In the first phase or login phase, it invokes each configured LoginModule to attempt the authentication. If all the necessary LoginModules succeed, then LoginContext enters the second phase where it invokes each LoginModule again to formally commit the authentication process. During this phase the Subject is populated with the authenticated principals and their credentials. If either of the phase fails, then the LoginContext invokes each configured module to abort the entire authentication attempt. Each LoginModule then cleans up any relevant state associated with the authentication attempt.
LoginContext has four constructors that can be used to instantiate it. All of them require the configuration entry name to be passed. In addition the Subject and/or a CallbackHandler can also be passed to the constructors.
The login modules invoked by JAAS must be able to garner information from the caller for authentication. For example the Kerberos login module may require users to enter their Kerberos password for authentication.
The LoginContext allows the application to specify a callbackhandler that the underlying login modules use to interact with users. There are two callback handlers available in Merlin (J2SE 1.4) - one based on the command line and another based on a GUI.
Sun provides an implementation of the UnixLoginModule, NTLoginModule, JNDILoginModule, KeyStoreLoginModule and Krb5LoginModule in Merlin. A smart card based JAAS login module is available from GemPlus [5].
The class com.sun.security.auth.module.Krb5LoginModule is Sun's implementation of a login module for the Kerberos version 5 protocol. Upon successful authentication the Ticket Granting Ticket (TGT) is stored in the Subject's private credentials set and the Kerberos principal is stored in the Subject's principal set.
Based on certain configurable options, Krb5LoginModule can also use an existing credentials cache, such as a native cache in the operating system, to acquire the TGT and/or use a keytab file containing the secret key to implicitly authenticate a principal. Both the Solaris and Windows 2000 platforms contain a credentials cache that Krb5LoginModule can use for fetching the TGT. Solaris also contains a system wide keytab file that Krb5LoginModule can use for fetching the secret key. On all platforms, Krb5LoginModule supports options to set the file path to a ticket cache or keytab file of choice. This is useful when third-party Kerberos support is installed and Java integration is desired. Please consult the documentation for Krb5LoginModule to learn about these options. In the absence of a native cache or keytab, the user will be prompted for the password and the TGT obtained from the KDC.
Figure 1 provides a sample JAAS login configuration entry for a client application. In this example, Krb5LoginModule will use the native ticket cache to get the TGT available in it. The authenticated identity will be the identity of the Kerberos principal that the TGT belongs to.
SampleClient { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true }; Figure 1. Sample client configuration entry
Figure 2 provides a sample login configuration entry for a server application. With this configuration, the secret key from the keytab is used to authenticate the principal "nfs/bar.example.com" and both the TGT obtained from the Kerberos KDC and the secret key are stored in the Subject's private credentials set. The stored key may be used later to validate a service ticket sent by a client (See the section on Java GSS-API.)
SampleServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true storeKey=true principal="nfs/bar.example.com" }; Figure 2. Sample server configuration entry
In the client code example shown in Figure 3, the configuration entry "SampleClient" will be used by the LoginContext. The TextCallbackHandler class will be used to prompt the user for the Kerberos password. Once the user has logged in, the Subject will be populated with the Kerberos Principal name and the TGT. Thereafter the user can execute code using Subject.doAs passing in the Subject obtained from the LoginContext.
LoginContext lc = null; try { lc = new LoginContext("SampleClient", new TextCallbackHandler()); // attempt authentication lc.login(); } catch (LoginException le) { ... } // Now try to execute ClientAction as the authenticated Subject Subject mySubject = lc.getSubject(); PrivilegedAction action = new ClientAction(); Subject.doAs(mySubject, action); Figure 3. Sample client code
ClientAction could be an action that is allowed only for authenticated Kerberos client Principals with a specific value.
Figure 4 shows server side sample code. It is similar to the client code shown in Figure 4 except for the application entry name and the PrivilegedAction.
LoginContext lc = null; try { lc = new LoginContext("SampleServer", new TextCallbackHandler()); // attempt authentication lc.login(); } catch (LoginException le) { ... } // Now try to execute ServerAction as the authenticated Subject Subject mySubject = lc.getSubject(); PrivilegedAction action = new ServerAction(); Subject.doAs(mySubject, action); Figure 4. Sample server code
To enable other vendors to provide their own Kerberos login module implementation that can be used with Java GSS-API, three standard Kerberos classes have been introduced in the javax.security.auth.kerberos package. These are KerberosPrincipal for Kerberos principals, KerberosKey for the long-term Kerberos secret key and KerberosTicket for Kerberos tickets. All implementations of the Kerberos login module must use these classes to store principals, keys and tickets in the Subject.
Upon successful authentication of a Subject, access controls can be enforced based upon the principals associated with the authenticated Subject. The JAAS principal based access controls augment the CodeSource access controls of Java 2. Permissions granted to a Subject are configured in Policy, which is an abstract class for representing the system wide access control policy. Sun provides a file based implementation of the Policy class. The Policy class is provider based so that others can provide their own policy implementation.
Enterprise applications often have varying security requirements and deploy a range of underlying technologies to achieve this. In such a scenario how do we develop a client-server application so that it can easily migrate from one technology to another? The GSS-API was designed in the Common Authentication Technology working group of the IETF to solve this problem by providing a uniform application programming interface for peer to peer authentication and secure communication that insulates the caller from the details of the underlying technology.
The API, described in a language independent form in RFC 2743 [6], accommodates the following security services: authentication, message confidentiality and integrity, sequencing of protected messages, replay detection, and credential delegation. The underlying security technology or "security mechanism" being used, has a choice of supporting one or more of these features beyond the essential one way authentication.Footnote 1
There are mainly two standard security mechanisms that the IETF has defined: Kerberos V5 [6] and the Simple Public Key Mechanism (SPKM) [8].
The API is designed such that an implementation may support multiple mechanisms simultaneously, giving the application the ability to choose one at runtime. Mechanisms are identified by means of unique object identifier's (OID's) that are registered with the IANA. For instance, the Kerberos V5 mechanism is identified by the OID {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2)}.
Another important feature of the API is that it is token based. i.e., Calls to the API generate opaque octets that the application must transport to its peer. This enables the API to be transport independent.
Figure 5. A multi-mechanism GSS-API implementation
The Java API for the Generic Security Service was also defined at the IETF and is documented in RFC 2853 [10]. Sun is pursuing the standardization of this API under the Java Community Process (JCP) [11] and plans to deliver a reference implementation with Merlin. Because the JCP is merely endorsing this externally defined API, the IETF assigned package namespace "org.ietf.jgss" will be retained in Merlin.
Sun's implementation of Java GSS-API, will initially ship with support for the Kerberos V5 mechanism only. Kerberos V5 mechanism support is mandatory for all Java GSS-API implementations in Java SE, although they are free to support additional mechanisms. In a future release, a Service Provider Interface (SPI) will be added so that new mechanisms can be configured statically or even at runtime. Even now the reference implementation in Merlin will be modular and support a private provider SPI that will be converted to public when standardized.
The Java GSS-API framework itself is quite thin, and all security related functionality is delegated to components obtained from the underlying mechanisms. The GSSManager class is aware of all mechanism providers installed and is responsible for invoking them to obtain these components.
The implementation of the default GSSManager that will ship with Java SE is obtained as follows:
GSSManager manager = GSSManager.getInstance();
The GSSManager can be used to configure new providers and to list all mechanisms already present. The GSSManager also serves as a factory class for three important interfaces: GSSName, GSSCredential, and GSSContext. These interfaces are described below with the methods to instantiate their implementations. For a complete API specification, readers are referred to [9] and [11].
Most calls to Java GSS-API throw a GSSException that encapsulate problems that occur both within the GSS-API framework, and within the mechanism providers.
This interface represents an entity for the purposes of Java GSS-API. An implementation of this interface is instantiated as follows:
GSSName GSSManager.createName(String name, Oid nameType) throws GSSException
For Example:
GSSName clientName = manager.createName("duke", GSSName.NT_USER_NAME);
This call returns a GSSName that represents the user principal "duke" at a mechanism independent level. Internally, it is assumed that each supported mechanism will map the generic representation of the user to a more mechanism specific form. For instance a Kerberos V5 mechanism provider might map this name to<EMAIL_ADDRESS>where EXAMPLE.COM is the local Kerberos realm. Similarly, a public key based mechanism provider might map this name to an X.509 Distinguished Name.
If we were referring to a principal that was not a user, but some sort of service, we would indicate that to the Java GSS-API call so that the mechanism knows to interpret it differently.
Example:
GSSName serverName =<EMAIL_ADDRESS>GSSName.NT_HOSTBASED_SERVICE);
The Kerberos V5 mechanism would map this name to the Kerberos specific form<EMAIL_ADDRESS>where EXAMPLE.COM is the realm of the principal. This principal represents the service nfs running on the host machine bar.example.com.
Sun's implementation of the GSSName interface is a container class. The container class lazily asks the individual providers to perform their mapping when their mechanism is used and then stores each mapped element in a set of principals. In this respect an implementation of GSSName is similar to the principal set stored in a Subject. It may even contain the same elements that are in a Subject's principal set, but its use is restricted to the context of Java GSS-API.
The name element stored by the Sun Kerberos V5 provider is an instance of a subclass of javax.security.auth.kerberos.KerberosPrincipal.
This interface encapsulates the credentials owned by one entity. Like the GSSName, this interface too is a multi-mechanism container.
Its implementation is instantiated as follows:
GSSCredential createCredential(GSSName name, int lifetime, Oid[] desiredMechs, int usage) throws GSSException
Here is an example of this call on the client side:
GSSCredential clientCreds = manager.createCredential(clientName, 8*3600, desiredMechs, GSSCredential.INITIATE_ONLY);
The GSSManager invokes the providers of the mechanisms listed in the desiredMechs for credentials that belong to the GSSName clientName. Additionally, it imposes the restriction that the credential must be the kind that can initiate outbound requests (i.e., a client credential), and requests a lifetime of 8 hours for it. The returned object contains elements from a subset of desiredMechs that had some credential available to satisfy this criteria. The element stored by the Kerberos V5 mechanism is an instance of a subclass of javax.security.auth.kerberos.KerberosTicket containing a TGT that belongs to the user.
Credential acquisition on the server side occurs as follows:
GSSCredential serverCreds = manager.createCredential(serverName, GSSCredential.INDEFINITE_LIFETIME, desiredMechs, GSSCredential.ACCEPT_ONLY);
The behavior is similar to the client case, except that the kind of credential requested is one that can accept incoming requests (i.e., a server credential). Moreover, servers are typically long lived and like to request a longer lifetime for the credentials such as the INDEFINITE_LIFETIME shown here. The Kerberos V5 mechanism element stored is an instance of a subclass of javax.security.auth.kerberos.KerberosKey containing the secret key of the server.
This step can be an expensive one, and applications generally acquire a reference at initialization time to all the credentials they expect to use during their lifetime.
The GSSContext is an interface whose implementation provides security services to the two peers.
On the client side a GSSContext implementation is obtained with the following API call:
GSSContext GSSManager.createContext(GSSName peer, Oid mech, GSSCredential clientCreds, int lifetime) throws GSSException
This returns an initialized security context that is aware of the peer that it must communicate with and the mechanism that it must use to do so. The client's credentials are necessary to authenticate to the peer.
On the server side the GSSContext is obtained as follows:
GSSContext GSSManager.createContext(GSSCredential serverCreds) throws GSSException
This returns an initialized security context on the acceptor's side. At this point it does not know the name of the peer (client) that will send a context establishment request or even the underlying mechanism that will be used. However, if the incoming request is not for service principal represented by the credentials serverCreds, or the underlying mechanism requested by the client side does not have a credential element in serverCreds, then the request will fail.
Before the GSSContext can be used for its security services it has to be established with an exchange of tokens between the two peers. Each call to the context establishment methods will generate an opaque token that the application must somehow send to its peer using a communication channel of its choice.
The client uses the following API call to establish the context:
byte[] GSSContext.initSecContext(byte[] inToken, int offset, int len) throws GSSException
The server uses the following call:
byte[] acceptSecContext(byte[] inToken, int offset, int len) throws GSSException
These two methods are complementary and the input accepted by one is the output generated by the other. The first token is generated when the client calls initSecContext for the first time. The arguments to this method are ignored during that call. The last token generated depends on the particulars of the security mechanism being used and the properties of the context being established.
The number of round trips of GSS-API tokens required to authenticate the peers varies from mechanism to mechanism and also varies with characteristics such as whether mutual authentication or one-way authentication is desired. Thus each side of the application must continue to call the context establishment methods in a loop until the process is complete.
In the case of the Kerberos V5 mechanism, there is no more than one round trip of tokens during context establishment. The client first sends a token generated by its initSecContext() containing the Kerberos AP-REQ message [2]. In order to generate the AP-REQ message, the Kerberos provider obtains a service ticket for the target server using the client's TGT. The service ticket is encrypted with the server's long-term secret key and is encapsulated as part of the AP-REQ message. After the server receives this token, it is passed to the acceptSecContext() method which decrypts the service ticket and authenticates the client. If mutual authentication was not requested, both the client and server side contexts would be established, and the server side acceptSecContext() would generate no output.
However, if mutual authentication were enabled, then the server's acceptSecContext() would generate an output token containing the Kerberos AP-REP [2] message. This token would need to be sent back to the client for processing by its initSecContext(), before the client side context is established.
Note that when a GSSContext is initialized on the client side, it is clear what underlying mechanism needs to be used. The Java GSS-API framework can obtain a context implementation from the appropriate mechanism provider. Thereafter, all calls made to the GSSContext object are delegated to the mechanism's context implementation. On the server side, the mechanism to use is not decided until the first token from the client side arrives.
Here is a class showing how the client side of an application would be coded. This is the ClientAction class that was executed using the doAs method in Figure 3:
class ClientAction implements PrivilegedAction { public Object run() { ... ... try { GSSManager manager = GSSManager.getInstance(); GSSName clientName = manager.createName("duke", GSSName.NT_USER_NAME); GSSCredential clientCreds = manager.createCredential(clientName, 8*3600, desiredMechs, GSSCredential.INITIATE_ONLY); GSSName peerName =<EMAIL_ADDRESS>GSSName.NT_HOSTBASED_SERVICE); GSSContext secContext = manager.createContext(peerName, krb5Oid, clientCreds, GSSContext.DEFAULT_LIFETIME); secContext.requestMutualAuth(true); // The first input token is ignored byte[] inToken = new byte[0]; byte[] outToken = null; boolean established = false; // Loop while the context is still not established while (!established) { outToken = secContext.initSecContext(inToken, 0, inToken.length); // Send a token to the peer if one was generated if (outToken != null) sendToken(outToken); if (!secContext.isEstablished()) { inToken = readToken(); else established = true; } } catch (GSSException e) { .... } ... ... } } Figure 6. Sample client using Java GSS-API
The corresponding section of code on the server side running the ServerAction class from Figure 5 is as follows:
class ServerAction implelemts PrivilegedAction { public Object run() { ... ... try { GSSManager manager = GSSManager.getInstance(); GSSName serverName =<EMAIL_ADDRESS>GSSName.NT_HOSTBASED_SERVICE); GSSCredential serverCreds = manager.createCredential(serverName, GSSCredential.INDEFINITE_LIFETIME, desiredMechs, GSSCredential.ACCEPT_ONLY); GSSContext secContext = manager.createContext(serverCreds); byte[] inToken = null; byte[] outToken = null; // Loop while the context is still not established while (!secContext.isEstablished()) { inToken = readToken(); outToken = secContext.acceptSecContext(inToken, 0, inToken.length); // Send a token to the peer if one was generated if (outToken != null) sendToken(outToken); } } catch (GSSException e) { ... } ... ... } } Figure 7. Sample server using Java GSS-API
Once the security context is established, it can be used for message protection. Java GSS-API provides both message integrity and message confidentiality. The two calls that enable this are as follows:
byte[] GSSContext.wrap(byte[] clearText, int offset, int len, MessageProp properties) throws GSSExceptionand
byte[] unwrap(byte[] inToken, int offset, int len, MessageProp properties) throws GSSException
The wrap method is used to encapsulate a cleartext message in a token such that it is integrity protected. Optionally, the message can also be encrypted by requesting this through a properties object. The wrap method returns an opaque token that the caller sends to its peer. The original cleartext is returned by the peer's unwrap method when the token is passed to it. The properties object on the unwrap side returns information about whether the message was simply integrity protected or whether it was encrypted as well. It also contains sequencing and duplicate token warnings.
Java GSS-API allows the client to securely delegate its credentials to the server, such that the server can initiate other security contexts on behalf of the client. This feature is useful for single sign-on in a multi-tier environment.
Figure 8. Credential Delegation
The client requests credential delegation prior to making the first call to initSecContext():
void GSSContext.requestCredDeleg(boolean state) throws GSSExceptionby setting state to true.
The server receives the delegated credential after context establishment:
GSSCredential GSSContext.getDelegCred() throws GSSException
The server can then pass this GSSCredential to GSSManager.createContext() pretending to be the client.
In the case of the Kerberos V5 mechanism, the delegated credential is a forwarded TGT that is encapsulated as part of the first token sent from the client to the server. Using this TGT, the server can obtain a service ticket on behalf of the client for any other service.
Previously we discussed how an application uses the GSSManager.createCredential() method to populate a GSSCredential object with mechanism specific credentials.The next two sub-sections will focus on how Java GSS-API mechanisms obtain these credentials. The mechanisms do not themselves perform a user login. Instead, the login is performed prior to using Java GSS-API and the credentials are assumed to be stored in some cache that the mechanism provider is aware of. The GSSManager.createCredential() method merely obtains references to those credentials and returns them in a GSS-centric container, the GSSCredential.
In the Java 2 platform we impose the restriction that the credentials cache that Java GSS-API mechanism providers use to obtain these elements must exclusively be the public and private credential sets in the Subject that is on the current access control context.
This model has the advantage that credential management is simple and predictable from the application's point of view. An application, given the right permissions, can purge the credentials in the Subject or renew them using standard Java API's. If it purged the credentials, it would be sure that the Java GSS-API mechanism would fail, or if it renewed a time based credential it would be sure that the mechanism would succeed.
Here is the sequence of events relevant to credential acquisition when the Kerberos V5 mechanism is used by the client application in Figures 3 and 6:
On the server side, when the Kerberos login is successful in step 2, Krb5LoginModule stores the KerberosKey for the server in the Subject in addition to the KerberosTicket. Later on the KerberosKey is retrieved in steps 5 through 7 and used to decrypt the service ticket that the client sends.
The default credential acquisition model for Java GSS-API requires credentials to be present in the current Subject. Typically, the credentials are placed there after a JAAS login by the application.
There might be cases where an application wishes to use Kerberos credentials from outside the Subject. It is recommended that such credentials be read as part of the initial JAAS login, either by configuring Krb5LoginModule to read them, or by writing a custom login module that reads them. However, some applications might have constrains that either prevent them from using JAAS prior to calling Java GSS-API, or force them to use some Kerberos mechanism provider that does not retrieve credentials from the current Subject.
In order to accommodate such cases while still retaining the standard model for others, the system property javax.security.auth.useSubjectCredsOnly was added. This system property serves as a boolean where a value of true requires that the standard credential acquisition model be followed, and a value of false permits the provider to use any cache of it choice. The default value of this property (when it is not set) will be assumed to be true.
If there is no valid Kerberos credential in the current Subject, and this property is true, then the Kerberos mechanism throws a GSSException. Setting this property to false does not necessarily mean that the provider has to use a cache other than the current Subject, it only gives the provider the latitude to do so if it wishes.
The Sun provider for the Kerberos V5 GSS-API mechanism always obtains credentials from a Subject. If there are no valid credentials in the current Subject, and this property is set to false, then the provider attempts to obtain new credentials from a temporary Subject by invoking a JAAS login itself. It uses the text callback handler for input/output with the user, and the JAAS configuration entry identified by"other" for the list of modules and options to use.Footnote 2
The Sun provider for the Kerberos V5 GSS-API mechanism assumes that one of these modules will be a Kerberos login module. It is possible to configure the modules listed under "other" to read a pre-existing cache so that the user is not unexpectedly prompted for a password in the middle of a Java GSS-API call. The new Subject that is populated by this login is discarded by the Kerberos GSS-API mechanism just as soon as the required credentials are retrieved from it.
An important class of applications that should be able to capitalize on Java single sign-on are applets. For this discussion we assume that the browser JRE has all the required packages or the Java plugin is used with a Merlin JRE installed by the user.
One complication in using applets arises mostly out of the fact that before an applet can use Java GSS-API, it must perform a JAAS login. The main problems with this are (a) an increase in the effort required on the part of the applet developer (b)unnecessary repeated login by the same user each time he or she starts an applet.
A good model to solve this problem would be to have the browser (or the Java plugin) perform a JAAS login once at startup. This would provide a Subject that could always be associated with the access control context whenever any Java code was run. As a result, the applet code would not need to perform a JAAS login prior to using Java GSS-API, and the user login would occur just once.
In the absence of this login functionality in the browser (or Java plugin), applets can still avoid having to perform a JAAS login themselves. To do so, the applets would have to set the javax.security.auth.useSubjectCredsOnly system property to false and use a GSS-API mechanism provider that is capable of obtaining credentials from sources other than current Subject. When using a Sun JRE with a Sun Kerberos GSS-API provider, expect the mechanism to perform a JAAS login to obtain new credentials as explained in the previous section. The applet deployer would only need to ensure that the appropriate modules and options are listed in the entry "other" in the JAAS configuration used by the JRE. This saves the applet developer from calling into JAAS API's directly, but it does not stop the repeated JAAS login that might happen with each applet the user runs. However, by configuring the login modules to read a pre-existing native cache, the deployer can both hide the login from the user, and minimize the overhead in the multiple logins. (See how this is done for the JAAS configuration entry "SampleClient" in Figure 1.)
The convenience of single sign-on also introduces new risks. What happens if a malicious user gains access to your unattended desktop from where he or she can start applets as you? What happens if malicious applets sign on as you to services that they are not supposed to?
For the former, we have no solution but to caution you against leaving your workstation unlocked! For the latter, we have many authorizations checks in place.
To illustrate some details of the permissions model consider an example where your browser has performed a JAAS login at startup time and associated a Subject with all applets that run in it.
The Subject is protected from rogue applets by means of the javax.security.auth.AuthPermission class. This permission is checked whenever code tries to obtain a reference to the Subject associated with any access control context.
Even if an applet were given access to a Subject, it needs a javax.security.auth.PrivateCredentialPermission to actually read the sensitive private credentials stored in it.
Other kinds of checks are to be done by Java GSS-API mechanism providers as they read credentials and establish security contexts on behalf of the credential's owner. In order to support the Kerberos V5 mechanism, two new permission classes have been added with the package javax.security.auth.kerberos:
ServicePermission(String servicePrinicipal, String action) DelegationPermission(String principals)
As new GSS-API mechanisms are standardized for Java SE, more packages will be added that contain relevant permission classes for providers of those mechanisms.
The Kerberos GSS-API mechanism permission checks take place at the following points in the program's execution:
The GSSManager.createCredential() method obtains mechanism specific credential elements from a cache such as the current Subject and stores them in a GSSCredential container. Allowing applets to acquire GSSCredential freely, even if they cannot use them to do much, is undesirable. Doing so leaks information about the existence of user and service principals. Thus, before an application can acquire a GSSCredential with any Kerberos credential elements in it, a ServicePermission check is made.
On the client side, a successful GSSCredential acquisition implies that a TGT has been accessed from a cache. Thus the following ServicePermission is checked:
<EMAIL_ADDRESS>"initiate");
The service principal<EMAIL_ADDRESS>represents the ticket granting service (TGS) in the Kerberos realm EXAMPLE.COM, and the action "initiate" suggests that a ticket to this service is being accessed. The TGS service principal will always be used in this permission check at the time of client side credential acquisition.
On the server side, a successful GSSCredential acquisition implies that a secret key has been accessed from a cache. Thus the following ServicePermission is checked:
<EMAIL_ADDRESS>"accept");
Here the service principal nfs/bar.example.com represents the Kerberos service principal and the action "accept" suggests that the secret key for this service is being requested.
An applet that has permissions to contact a particular server, say the LDAP server, must not instead contact a different server such as the FTP server. Of course, the applet might be restricted from doing so with the help of SocketPermission. However, it is possible to use ServicePermission to restrict it from authenticating using your identity, even if the network connection was permitted.
When the Kerberos mechanism provider is about to initiate context establishment it checks the ServicePermission:
<EMAIL_ADDRESS>"initiate");
This check prevents unauthorized code from obtaining and using a Kerberos service ticket for the principal<EMAIL_ADDRESS>Providing limited access to specific service principals using this permission is still dangerous. Downloaded code is allowed to communicate back with the host it originated from. A malicious applet could send back the initial GSS-API output token that contains a KerberosTicket encrypted in the target service principal's long-term secret key, thus exposing it to an offline dictionary attack. For this reason it is not advisable to grant any "initiate" ServicePermission to code downloaded from untrusted sites.
On the server side, the permission to use the secret key to accept incoming security context establishment requests is already checked during credential acquisition. Hence, no checks are made in the context establishment stage.
An applet that has permission to establish a security context with a server on your behalf also has the ability to request that your credentials be delegated to that server. But not all servers are trusted to the extent that your credentials can be delegated to them. Thus, before a Kerberos provider obtains a delegated credential to send to the peer, it checks the following permission:
DelegationPermission("<EMAIL_ADDRESS><EMAIL_ADDRESS>");
This permission allows the Kerberos service principal<EMAIL_ADDRESS>to receive a forwarded TGT (represented by the ticket granting service krbtgt/EXAMPLE.COM@EXAMPLE.COM).Footnote 3
In this paper we have presented a framework to enable single sign-on in Java. This requires sharing of credentials between JAAS which does the initial authentication to obtain credentials, and Java GSS-API which uses those credentials to communicate securely over the wire. We have focused on Kerberos V5 as the underlying security mechanism, but JAAS's stackable architecture and Java GSS-API's multi-mechanism nature allow us to use any number of different mechanisms simultaneously.
The Kerberos login module for JAAS is capable of reading native caches so that users do not have to authenticate themselves beyond desktop login on platforms that support Kerberos. Moreover, the Kerberos V5 mechanism for Java GSS-API allows credentials to be delegated which enables single sign-on in multi-tier environments.
Finally, a number of permissions checks are shown to prevent the unauthorized use of the single-sign on features provided by Kerberos.
We thank Gary Ellison, Charlie Lai, and Jeff Nisewanger for their contribution at each stage of the Kerberos single sign-on project. JAAS 1.0 was implemented by Charlie as an optional package for Kestrel (J2SE 1.3). Gary has been instrumental in designing the permissions model for the Kerberos Java GSS-API mechanism. We are grateful to Bob Scheifler for his feedback on integrating JAAS 1.0 into Merlin and to Tim Blackman for the KeyStoreLoginModule and CallbackHandler implementations. We also thank Bruce Rich, Tony Nadalin, Thomas Owusu and Yanni Zhang for their comments and suggestions. We thank Mary Dageforde for the documentation and tutorials. Sriramulu Lakkaraju, Stuart Ke and Shital Shisode contributed tests for the projects. Maxine Erlund provided management support for the project.
Footnote 1 The GSS-API Kerberos mechanism performs client authentication at the minimum.
Footnote 2 Actually it first tries to use the JAAS configuration entry"com.sun.security.jgss.initiate" for the client and "com.sun.security.jgss.accept" for the server and falls back on the entry for "other", if these entries are missing. This gives system administrators some additional control over its behavior.
Footnote 3 The use of two principal names in this permission allows for finer grained delegation such as proxy tickets for specific services unlike a carte blanche forwarded TGT. Even though the GSS-API does not allow for proxy tickets, another API such as JSSE might support this idea at some point in the future.