Security
Dynamic P2P networks, such as the JXTA network, need to support different levels of resource access. JXTA peers
operate in a role-based trust model, in which an individual peer acts under the authority granted to it by another
trusted peer to perform a particular task.
Five basic security requirements must be provided:
• Confidentiality — guarantees that the contents of a message are not disclosed to unauthorized individuals.
• Authentication — guarantees that the sender is who he or she claims to be.
• Authorization — guarantees that the sender is authorized to send a message.
• Data integrity — guarantees that the message was not modified accidentally or deliberately in transit.
• Refutability — guarantees that the message was transmitted by a properly identified sender and is not a
replay of a previously transmitted message.
XML messages provide the ability to add meta-data such as credentials, certificates, digests, and public keys to
JXTA messages, enabling these basic security requirements to be met. Message digests and signatures guarantee
the data integrity of messages. Messages may also be encrypted and signed for confidentiality and refutability.
Credentials can be used to provide message authentication and authorization.
A credential is a token that is used to identify a sender, and it can be used to verify a sender’s right to send a message
to a specified endpoint. The credential is an opaque token that must be presented each time a message is sent. The
sending address placed in a JXTA message envelope is cross-checked with the sender’s identity in the credential. Each
credential’s implementation is specified as a plug-in configuration, which allows multiple authentication
configurations to co-exists on the same network.
It is the intent of the JXTA protocols to be compatible with widely accepted transport-layer security mechanisms
for message-based architectures, such as Secure Sockets Layer (SSL) and Internet Protocol Security (IPSec).
IDs
Peers, peer groups, pipes and other JXTA resources need to be uniquely identifiable. A JXTA ID uniquely identifies a
resource and serves as a canonical way of referring to that resource. Currently, there are six types of JXTA entities
which have JXTA ID types defined: peers, peer groups, pipes, content, module classes, and module specifications.
URNs are used to express JXTA IDs. URNs
1
are a form of URI that “... are intended to serve as persistent,
location-independent, resource identifiers”. Like other forms of URI, JXTA IDs are presented as text.
An example JXTA peer ID is:
urn:jxta:uuid-59616261646162614A78746150325033F3BC76FF13C2414CBC0AB663666DA53903
An example JXTA pipe ID is:
urn:jxta:uuid-59616261646162614E504720503250338E3E786229EA460DADC1A176B69B731504
Every JXTA ID has an ID Format. The format describes how the ID was generated and how it may be
manipulated by programs. Every ID indicates it's format immediately after the urn:jxta: prefix. There are two
common JXTA ID Formats, uuid and jxta, though others exist. The jxta format is used for special common
identifiers such as the IDs of the World Peer Group and the Network Peer Group. The uuid format is used for
most other IDs. The uuid format provides randomly generated unique IDs and is based upon DCE
GUID/UUIDs
2
. The portion of a JXTA ID which follows the ID Format is specific to each ID Format and is
often opaque—you aren't meant to be able to decode it directly from the URI. In the prece
1 See IETF RFC 2141 for more information on URNs.
2 See “The Open Group - DCE 1.1 Remote Procedure Call (RPC) : Appendix A - Universal Unique Identifier”
http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
JXSE 2.5 Programmers Guide : JXTA Concepts 20