/*

 * Copyright (c) 2000, 2019, 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.

 */

/**

 * 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}

 * 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.

 *

 * <h2 id="useSubjectCredsOnly">Credential Acquisition</h2>

 * 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:

 * {@systemProperty javax.security.auth.useSubjectCredsOnly}. By default

 * this system property will be assumed to be {@code true} (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>

 * For an online tutorial on using Java GSS-API, please see

 * {@extLink security_guide_jgss_tutorial

 * Introduction to JAAS and Java GSS-API}.

 *

 * @since 1.4

 * */

package org.ietf.jgss;