65 lines
4.3 KiB
HTML
65 lines
4.3 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Security mechanisms" />
|
||
|
|
<meta name="abstract" content="The GSS-API consists of an abstract framework over one or more underlying security mechanisms. How the framework interacts with the underlying security mechanisms is implementation specific." />
|
||
|
|
<meta name="description" content="The GSS-API consists of an abstract framework over one or more underlying security mechanisms. How the framework interacts with the underlying security mechanisms is implementation specific." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzahajgssconcept.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzahajgssconcept50" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Security mechanisms</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzahajgssconcept50"><a name="rzahajgssconcept50"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Security mechanisms</h1>
|
||
|
|
<div><p>The GSS-API consists of an abstract framework over one or more
|
||
|
|
underlying security mechanisms. How the framework interacts with the underlying
|
||
|
|
security mechanisms is implementation specific.</p>
|
||
|
|
<div class="p">Such implementations exist in two general categories: <ul><li>At one extreme, a monolithic implementation tightly binds the framework
|
||
|
|
to a single mechanism. This kind of implementation precludes the use of other
|
||
|
|
mechanisms or even different implementations of the same mechanism.</li>
|
||
|
|
<li>At the other end of the spectrum, a highly modular implementation offers
|
||
|
|
ease of use and flexibility. This kind of implementation offers the ability
|
||
|
|
to seamlessly and easily plug different security mechanisms and their implementations
|
||
|
|
into the framework. </li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p>IBM<sup>®</sup> JGSS
|
||
|
|
falls into the latter category. As a modular implementation, IBM JGSS leverages
|
||
|
|
the provider framework defined by the Java™ Cryptographic Architecture (JCA) and
|
||
|
|
treats any underlying mechanism as a (JCA) provider. A JGSS provider supplies
|
||
|
|
a concrete implementation of a JGSS security mechanism. An application can
|
||
|
|
instantiate and use multiple mechanisms.</p>
|
||
|
|
<p>It is possible for a provider to support multiple mechanisms, and JGSS
|
||
|
|
makes it easy to use different security mechanisms. However, the GSS-API does
|
||
|
|
not provide a means for two communicating peers to choose a mechanism when
|
||
|
|
multiple mechanisms are available. One way to choose a mechanism is to
|
||
|
|
start with the Simple And Protected GSS-API Negotiating Mechanism (SPNEGO),
|
||
|
|
a pseudo-mechanism that negotiates an actual mechanism between the two peers. IBM JGSS
|
||
|
|
does not include a SPNEGO mechanism.</p>
|
||
|
|
<p>For more information about SPNEGO, see Internet Engineering Task Force
|
||
|
|
(IETF) RFC 2478 <a href="http://www.ietf.org/rfc/rfc2478.txt" target="_blank">The Simple and Protected GSS-API Negotiation Mechanism</a> </p>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzahajgssconcept.htm" title="JGSS operations consist of four distinct stages, as standardized by the Generic Security Service Application Programming Interface (GSS-API).">JGSS concepts</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|