Mercurial > hg > openjdk > jdk9 > jdk

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<!--
Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.
DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

This code is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License version 2 only, as
published by the Free Software Foundation.  Oracle designates this
particular file as subject to the "Classpath" exception as provided
by Oracle in the LICENSE file that accompanied this code.

This code is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
version 2 for more details (a copy is included in the LICENSE file that
accompanied this code).

You should have received a copy of the GNU General Public License version
2 along with this work; if not, write to the Free Software Foundation,
Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
or visit www.oracle.com if you need additional information or have any
questions.
-->

</head>
<body bgcolor="white">

    This package presents a framework that allows application developers to
    make use of security services like authentication, data integrity and
    data confidentiality from a variety of underlying security mechanisms
    like Kerberos, using a unified API. The security mechanisms that an
    application can
    chose to use are identified with unique object identifiers. One example
    of such a mechanism is the Kerberos v5 GSS-API mechanism (object
    identifier 1.2.840.113554.1.2.2). This mechanism is available through
    the default instance of the GSSManager class.<p>

    The GSS-API is defined in a language independent way in
    <a href=http://www.ietf.org/rfc/rfc2743.txt>RFC 2743</a>. The Java
    language bindings are defined in
    <a href=http://www.ietf.org/rfc/rfc2853.txt>RFC 2853</a><p>

    An application starts out by instantiating a <code>GSSManager</code>
    which then serves as a factory for a security context. An application
    can use specific principal names and credentials that are also created
    using the GSSManager; or it can instantiate a
    context with system defaults. It then goes through a context
    establishment loop. Once a context is established with the
    peer, authentication is complete. Data protection such as integrity
    and confidentiality can then be obtained from this context.<p>

    The GSS-API does not perform any communication with the peer. It merely
    produces tokens that the application must somehow transport to the
    other end.

<h3 id="useSubjectCredsOnly">Credential Acquisition</h3>
    The GSS-API itself does not dictate how an underlying mechanism
    obtains the credentials that are needed for authentication. It is
    assumed that prior to calling the GSS-API, these credentials are
    obtained and stored in a location that the mechanism provider is
    aware of. However, the default model in the Java platform will be
    that mechanism providers must obtain credentials only from the private
    or public credential sets associated with the
    {@link javax.security.auth.Subject Subject} in the
    current access control context.  The Kerberos v5
    mechanism will search for the required INITIATE and ACCEPT credentials
    ({@link javax.security.auth.kerberos.KerberosTicket KerberosTicket} and
     {@link javax.security.auth.kerberos.KerberosKey KerberosKey}) in
    the private credential set where as some other mechanism might look
    in the public set or in both.  If the desired credential is not
    present in the appropriate sets of the current Subject, the GSS-API
    call must fail.<p>

    This model has the advantage that credential management
    is simple and predictable from the applications 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 JGSS mechanism would fail,
    or if it renewed a time based credential it would be sure that a JGSS
    mechanism would succeed.<p>

    This model does require that a {@link
    javax.security.auth.login JAAS login} be performed in order to
    authenticate and populate a Subject that the JGSS mechanism can later
    utilize. However, applications have the ability to relax this
    restriction by means of a system property:
    <code>javax.security.auth.useSubjectCredsOnly</code>. By default
    this system property will be assumed to be <code>true</code> (even when
    it is unset) indicating that providers must only use the credentials
    that are present in the current Subject. However, if this property is
    explicitly set to false by the application, then it indicates that
    the provider is free to use any credentials cache of its choice. Such
    a credential cache might be a disk cache, an in-memory cache, or even
    just the current Subject itself.

<h2>Related Documentation</h2>
<p>
For an online tutorial on using Java GSS-API, please see
{@extLink security_guide_jgss_tutorial
Introduction to JAAS and Java GSS-API}.
</p>

<!--
<h2>Package Specification</h2>

##### FILL IN ANY SPECS NEEDED BY JAVA COMPATIBILITY KIT #####
<ul>
  <li><a href="">##### REFER TO ANY FRAMEMAKER SPECIFICATION HERE #####</a>
</ul>

<h2>Related Documentation</h2>

For overviews, tutorials, examples, guides, and tool documentation, please see:
<ul>
  <li><a href="">##### REFER TO NON-SPEC DOCUMENTATION HERE #####</a>
</ul>

-->

@since 1.4
</body>
</html>
author	wetmore
date	Tue, 20 Jun 2017 12:57:42 -0700
parents	d9719d51c343
children