archive/jdk
1
0
Fork 0
mirror of https://github.com/openjdk/jdk.git synced 2025-09-16 00:54:38 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

8214568: Use {@systemProperty} for definitions of system properties

Browse source 
Reviewed-by: xuelei
This commit is contained in:
Weijun Wang 2018-12-13 12:03:03 +08:00
parent 9136c7d1d0
commit cf21c5ef11
5 changed files with 131 additions and 136 deletions
Download patch file Download diff file Expand all files Collapse all files

10
src/java.security.jgss/share/classes/javax/security/auth/kerberos/package-info.java
View file

@ -1,5 +1,5 @@
/* /*
* Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
* *
* This code is free software; you can redistribute it and/or modify it * This code is free software; you can redistribute it and/or modify it
@ -38,10 +38,10 @@
* *
* You can provide the name of your default realm and Key Distribution * You can provide the name of your default realm and Key Distribution
* Center (KDC) host for that realm using the system properties * Center (KDC) host for that realm using the system properties
* {@code java.security.krb5.realm} and {@code java.security.krb5.kdc}. * {@systemProperty java.security.krb5.realm} and
* Both properties must be set. * {@systemProperty java.security.krb5.kdc}. Both properties must be set.
* Alternatively, the {@code java.security.krb5.conf} system property can * Alternatively, the {@systemProperty java.security.krb5.conf} system property
* be set to the location of an MIT style {@code krb5.conf} configuration * can be set to the location of an MIT style {@code krb5.conf} configuration
* file. If none of these system properties are set, the {@code krb5.conf} * file. If none of these system properties are set, the {@code krb5.conf}
* file is searched for in an implementation-specific manner. Typically, * file is searched for in an implementation-specific manner. Typically,
* an implementation will first look for a {@code krb5.conf} file in * an implementation will first look for a {@code krb5.conf} file in

121
src/java.security.jgss/share/classes/org/ietf/jgss/package-info.java Normal file
View file

@ -0,0 +1,121 @@
/*
* Copyright (c) 2000, 2018, 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.
*
* <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:
* {@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>
* <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
* */
package org.ietf.jgss;

126
src/java.security.jgss/share/classes/org/ietf/jgss/package.html
View file

@ -1,126 +0,0 @@
<!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>

6
src/jdk.security.auth/share/classes/com/sun/security/auth/login/ConfigFile.java
View file

@ -1,5 +1,5 @@
/* /*
* Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
* *
* This code is free software; you can redistribute it and/or modify it * This code is free software; you can redistribute it and/or modify it
@ -55,8 +55,8 @@ import java.net.URI;
* each configuration. * each configuration.
* *
* <li> * <li>
* The {@code java.lang.System} property * The system property
* <i>java.security.auth.login.config</i> * {@systemProperty java.security.auth.login.config}
* may also be set to a {@code URL} pointing to another * may also be set to a {@code URL} pointing to another
* login configuration file * login configuration file
* (which is the case when a user uses the -D switch at runtime). * (which is the case when a user uses the -D switch at runtime).

4
src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
View file

@ -1,5 +1,5 @@
/* /*
* Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
* *
* This code is free software; you can redistribute it and/or modify it * This code is free software; you can redistribute it and/or modify it
@ -84,7 +84,7 @@ import static sun.security.util.ResourcesMgr.getAuthResourceString;
* by using the option {@code principal}. The principal name * by using the option {@code principal}. The principal name
* can either be a simple user name, a service name such as * can either be a simple user name, a service name such as
* {@code host/mission.eng.sun.com}, or "*". The principal can also * {@code host/mission.eng.sun.com}, or "*". The principal can also
* be set using the system property {@code sun.security.krb5.principal}. * be set using the system property {@systemProperty sun.security.krb5.principal}.
* This property is checked during login. If this property is not set, then * This property is checked during login. If this property is not set, then
* the principal name from the configuration is used. In the * the principal name from the configuration is used. In the
* case where the principal property is not set and the principal * case where the principal property is not set and the principal