UDDI v2
A. Security model
1. The Inquiry and Publishers API functions are exposed as SOAP messages over
HTTP. HTTPS (specifically SSL 3.0) is used for all publisher API calls. No
authentication is required to make use of the Inquiry API functions. Operator Sites
will each provide a service description that exposes a bindingTemplate that makes use
of HTTPS and SSL to secure the transmission of data.
2. Each of the calls in the publishers API that change information at a given Operator
Site requires the use of authentication token (authinfo). These authinfo tokens are
meaningful only to the Operator Site that provided them and are to be used according
to the published policies of a given Operator Site.
3. Before any party can publish data within an Operator Site, credentials and
permission to publish must be established with the individual operator. The specifics
of these establishing credentials is Operator Site dependant, and all valid Operator
Sites will provide a Web-based user interface via which to establish an identity and
secure permissions to publish data.
4. The only requirement placed on token generation for use with the publishers API is
that the tokens themselves must be valid string text that can be placed within the
authInfo XML element. Authentication tokens are not required to be valid except at
the Operator Site or implementation from which they originated.
5. These tokens need only have meaning at a single Operator Site or implementation,
and will not be expected to work across sites.
The get_authToken message is provided to accommodate those implementations that
desire a login step (for ex:- username/password schemes).
6. Certificate based authentication and similar security mechanisms do not require this
additional step of “logging in” and can directly pass compatible authentication token
information (such as a certificate value) within the authInfo element provided on each
of the publishers API messages. If certificate based authentication or similar security
is employed by the choice of a given Operator Site, the use of the get_authToken and
discard_authToken messages is optional.
B. Security policy
1. Each Node Operator is responsible for implementing its own security mechanisms,
but each must have a set of clearly stated policies for data replication, data integrity
and confidentiality, availability, administration, and audit registered with the other
UDDI operators participating in the replication cloud, and visibly posted on their
UDDI registry web site.
2. Each operator is responsible for implementing its own access control mechanism,
and for properly generating UUIDs for the keyed entities saved at its site. It is also
responsible to generate the operator and authorizedName attributes of businessEntity
and tModel elements saved at its site. The value of the authorizedName attribute shall
be sufficient for the custodial operator to uniquely identify a publisher account as
required to carry out the required authorization and audit functions.
4. The data that must be protected includes the business entities, tModels, and
relationship assertions (hosted locally and replicated from other Node Operators), the
replication configuration files, and any file containing ownership, permission, or
access control information.
5. All save, update, and delete operations upon businessEntity, businessService,
bindingTemplate, and tModel entities must be audited, be they through a Node
Operator's user interface or through the specified UDDI API. For such operations, the
following items must be made manifest in the audit log.
o An identification of the publisher account on whose authority the
publish, update, or delete was carried out,
o An identification of the instant in time at that Operator Node at which
the operation occurred,
o If invoked through the UDDI network API, the name of the API used
to carry out the operation,
o The UUID keys which identify the top-level entity(s) involved,
o The local USN assigned to the operation in the operator's change
record journal. Note that multiple change records may be generated
from a single save or delete operation. In this case, unique journal
entries should be made for each entry updated, each with an identical
time instant.
6. Registrations of new authorized publishers at each Operator Node must be audited.
For such registrations, at least the following information must be recorded.
o An identification of the publisher account that was created,
o An identification of the instant in time at that Operator Node at which
the operation occurred,
o An email address by which the publisher can be contacted.
7. The data custody transfer from one publisher account to another must be audited at
both the new and originating Operator Nodes. The following audit information must
be recorded for such change requests.
o An identification of the publisher account on whose authority the
custody transfer operation was carried out,
o When the change of custody is completed, the local USN assigned to
the change record for the custody transfer in the Node Operator's
change record journal,
o An identification of the instant in time at that Operator Node at which
the operation occurred,
o The UUID keys of the UDDI data whose custody was transferred,
o The UUID of both the custody-relinquishing and custody-accepting
Operator Nodes involved in the transfer.
8. The receipt of change records from other nodes during replication must be audited.
The following audit information must be recorded for such change records.
o The local USN assigned to the operation in the operator's change
record journal.
o The UUID of the originating node and the originating USN associated
with the change record.
9. Operators must obtain their X.509 V3 certificate from any of the following
Certificate Authorities:
Verisign: Secure Server Security CA (http://www.verisign.com)
Equifax: Thawte Server CA (http://www.equifax.com)
C. Implementations of v2
Juddi
1. juddi implements authenticated access to use the publishers API as defined in
UDDIv2. That is, authentication is done with password and username. The transfer of
password and username is encrypted with HTTPS (although it is possible to install
juddi in a domain/apache server without a certificate).
2. Three authentication modules are supplied with juddi. User can implement custom
authentication modules simply by implementing the Authenticator interface.
3. The three authentication modules bundled with the distribution are:
a. XMLDocAuthenticator This is a simple implementation of jUDDI's Authenticator
interface. The credential store is simply an unencrypted xml document called
'juddi.users' that can be found in jUDDI's config directory.
* Example juddi.users document:
* =============================
*
*
*
*
*
*
*
b. CryptedXMLDocAuthenticator
Same as above, but uses javax.crypto.* to encrypt the passwords
c. JBossAuthenticator
An implementation of jUDDI's Authenticator interface that uses the JBoss
authentication manager. This is for deployment onto the jBoss application server.
Doesn’t support signatures as yet.
UDDI v3
A. Digital signatures
1. UDDI entities can be digitally signed (W3C XML digital signature standard). Inquirers
of a registry will filter their queries, only requesting data that has in fact been signed (by
retrieving and verifying that the queries have valid signatures). Publishers to a registry
now have the assurance that they are not being misrepresented by someone claiming to
own a UDDI entity.
2. Signatures allows data integrity to be guaranteed while copying between registries and
therefore provides support for the multiple registry environment of v3.
B. Security API
1. The security API is contains the same as v2, but is now categorized as a separate API
includes the following API calls:
· discard_authToken: Used to inform a node that a previously obtained
authentication token is no longer required and should be considered invalid
if used after this message is received.
· get_authToken: Used to request an authentication token in the form of
an authInfo element from a UDDI node. An authInfo element MAY be
required when using the API calls defined Inquiry API Set, Publication
API Set, Custody and Ownership Transfer API Set, and Subscription API
Set.
Whether authInfo elements are required on API calls is determined by node policy. In the
event that an authInfo element is not discarded, a node MAY choose to expire the
authentication token so it is no longer valid for authentication in API calls after a period of
time.
2. A UDDI node typically does not support the Security API set if it does not support using
an authInfo element in any API set. If the node does support using an authInfo element in
any of the API set provided by the node, it SHOULD support the Security API set. A
node MAY provide an alternative mechanism for obtaining authInfo elements.
B. Policies
1. Policies are used to provide flexibility for implementations to support different
operational policies for different UDDI registry implementations - internet, extranet,
intranet, development, test, production, etc. Policies must be established and consistently
determined by inquirers of a UDDI node.
2. UDDI security-related aspects that have been identified as policy decisions include the
following: authorization models, data custody and confidentiality, key generation and audit
policy. The security model for a UDDI registry can be characterized by the collection of
registry and node policies and the implementation of these policies by a UDDI node.
3. In order to authorize or restrict access to data in a UDDI registry, an implementation of
a UDDI node MAY be integrated with one or more identification systems. An
implementation specific policy MUST identify the identification system(s) used.
4. Integration of UDDI APIs and data with an identification system MAY be implemented
through the authentication and authorization APIs to provide access control as described in
the Security Policy API. Other authentication and authorization mechanisms and policies
are represented in UDDI through use of tModels to describe the Web services of a UDDI
node.
C. Policy representation
1. There are two types of polices defined in the following sections. There are policies that
can be communicated through representation in an XML document and there are policies
that can be modeled within UDDI through the use of UDDI elements.
2. Policies communicated through an XML document SHOULD include the name of the
policy abstraction from this section, a description of the policy rule and a declaration of the
policy decision point and the policy enforcement point.
3. When documenting policies, there is a hierarchy in the way policies are defined. A
registry defines the broad registry policy abstractions, one of which is whether or not a
policy may be defined by the individual nodes within the registry. If a registry allows
nodes to specify policies, there is said to be a delegation of the policy expression to the
node.
D. Security-related policies
UDDI defines a large number of abstract registry policies, some mandatory and some
optional. These are those that are the most closely related to security:
1. Registry keying policy - A registry MUST have a policy on key format and key
generation. The registry MUST have a policy on data integrity or how the
keyspace is protected from unauthorized modification.
2. UDDI Information Access Control Policy - UDDI nodes that maintain custody of
UDDI information and implement a data storage mechanism are responsible for
the Data Model of the underlying storage of the data elements and its mapping to
the Information Model. The mapping to the information model is represented by
the implementation of the API sets defined in this specification.
3. Registry Authorization Policy - A registry MUST have a policy on access to the
information registered in it. A registry may specify a policy of global access for all
API’s or it may specify a different type of access for each API and/or each
publisher. The registry policy MAY specify that the authInfo element is required
for an API. The policy describing who has access to what information is called the
authorization policy.
4. Delegation of authorization policy - A registry MAY allow nodes to specify their
own access policies (delegation of policy), but an individual node’s access policy
MUST be consistent with that of the other nodes in the registry and MUST NOT
compromise the data in the registry as a whole.
5. Modeling Authorization - A policy that requires authorization to use a particular
UDDI API set SHOULD be represented in the structures of the Node Business
Entity element. An authorization concept used by an implementation of a UDDI
API set SHOULD be represented by a tModel. This tModel SHOULD be
referenced in the bindingTemplate implementing a UDDI API set that uses the
particular authorization concept.
6. Registry Approved Certificate Authorities - Each registry MUST establish the
certificate authorities it recognizes. A registry MAY delegate this policy to a node.
7. Registry Data Confidentiality - A registry MAY have a policy for protecting the
information under the custody of its nodes from unauthorized access. This policy
has two dimensions.
8. Persistent Data Confidentiality - A registry MAY specify a policy for the
encryption of UDDI data when stored .This policy MAY be delegated to the node
to implement and is usually referred to as persistent data confidentiality
9. Transient Data Confidentiality - The data supplied in an API MAY need to be
protected from being “sniffed” on the wire while being transmitted. This
confidentiality (or the encryption of the information) MAY be specified as part of
the transport of the API. Each API set MAY have different policies for Data
Confidentiality.
10. Modeling Data Confidentiality - The RECOMMENDED means of conveying the
policy for data confidentiality in transmission is to include a tModelInstanceInfo
referencing a tModel that represents the mechanism for confidentiality in the
binding for the UDDI API set.
11. Registry Audit Policy - A registry MAY specify a policy for the recording of
information to maintain an account of the activity that has been processed. The
audit policy MAY be delegated to the nodes in a registry. The audit policy
SHOULD state what actions are audited and under what conditions. Also, the
audit policy SHOULD state who has access to the audit trail.
12. Registry Privacy Policy - A registry MAY specify a policy for protecting the
information collected about users of the registry. The privacy policy MAY be
delegated to the nodes in a registry.
13. Authorization for Subscription - A registry MUST specify a policy for deciding
who is able to create, subscribe to and receive subscriptions including whether
each node may have its own policies on subscription. The policies that include
authorization SHOULD be reconciled with other authorization policies including
the registries policy for authorization of APIs.
E. Implementations of v3
Systinet Registry 5.0
1. Includes a GUI tool for signing, verifying and configuring XML signatures on UDDI
data structures
2. Provides an implementation of ACL-permission structure to UDDI data structures.
Explicit permissions are saved with the entity as special KeyedReferences in the
categoryBag, and only the owner can change them.
3. ACL permissions are represented as tModels as detailed below:
ACL
v3 tModelKey v2 tModelKey
Permission
find allowed uddi:systinet.com:acl:find- uuid:aacfc8e0-dcf5-11d5-b238-
allowed cbbeaea0a8d4
find denied uddi:systinet.com:acl:find-denied uuid:ced3c160-dcf5-11d5-b238-
cbbeaea0a8d4
get allowed uddi:systinet.com:acl:get- uuid:f9977a90-dcf5-11d5-b238-
allowed cbbeaea0a8d4
get denied uddi:systinet.com:acl:get-denied uuid:09e202d0-dcf6-11d5-b238-
cbbeaea0a8d4
save allowed uddi:systinet.com:acl:save- uuid:19885bd0-dcf6-11d5-b239-
allowed cbbeaea0a8d4
save denied uddi:systinet.com:acl:save- uuid:2a25e610-dcf6-11d5-b239-
denied cbbeaea0a8d4
delete allowed uddi:systinet.com:acl:delete- uuid:37f44ac0-dcf6-11d5-b239-
allowed cbbeaea0a8d4
delete denied uddi:systinet.com:acl:delete- uuid:4e51d8f0-dcf6-11d5-b239-
ACL
v3 tModelKey v2 tModelKey
Permission
denied cbbeaea0a8d4
create allowed uddi:systinet.com:acl:create- uuid:5bc32980-dcf6-11d5-b239-
allowed cbbeaea0a8d4
create denied uddi:systinet.com:acl:create- uuid:6d0be7e0-dcf6-11d5-b239-
denied cbbeaea0a8d4
4. In UDDI v3, explicit ACL permission is saved in a special keyedReferenceGroup
having the tModelKey uddi:systinet.com:acl. This keyedReferenceGroup can
contain only keyedReferences to ACL tModels. Only the terms "user" and "group" are
allowed in the included keyName, and the keyValue must contain the name of the
user or group (according to keyName value). For example, user demo_john can save
(update) following businessEntity even if he is not the owner:
Example 1. Setting ACLs - v3
...
...
...
GT4
1. GT4 security mechanisms that can be used to secure Grimoires
WS-SecureMessage: sign the SOAP message using certificate.
Client side configuration file (client-security-config.xml)
Client program
// Client secure configuration
private static final String CLIENT_DESC = "hello/client-security-config.xml";
((Stub)helloPort)._setProperty(Constants.CLIENT_DESCRIPTOR_FILE,
CLIENT_DESC);
Service side configuration file
Get caller’s identity (the subject in caller’s certificate) in the service
import org.globus.wsrf.security.SecurityManager;
String identity = SecurityManager.getManager().getCaller();
System.out.println("Caller's identity: " + identity);
Caller's identity: /O=Grid/OU=GlobusTest/OU=simpleCA-
cornfed.ecs.soton.ac.uk/OU=ecs.soton.ac.uk/CN=gt4test
Implement authorization in Grimoires’ business logic. (GT4 takes care of
authentication.)