p4.7.3 generic authentication, authorization and ...fredwan.net/papers folder/p4.7.3.pdf ·...

P4.7.3

Generic Authentication, Authorization and Accounting Toolkit

Reference Component (III) Revised Design

Workpackage: WP4.7 Foundations Author: Fred Wan UvA Authorized by: Cees de Laat UvA Doc Ref: P4.7.3 Reviewer Lorenzo Blasi HP Dissemination Level

Public

Date Author Comments Version Status 12.09.2007 Fred Wan Revision draft for review 0.1 Draft 13.10.2007 Fred Wan Draft updated after review 1.0 Final 24.10.2007 Fred Wan 1.1 Internal QA

Approved

This document is for public dissemination © UvA

NextGRID: Deliverable P4.7.3 of 114

Executive Summary This document is the covering document of the P4.7.3 software component deliverable. It describes the implementation of the Authentication, Authorization and Accounting (AAA) concepts as laid down in RFC 2903 and 2904 [1], [2]. The efforts undertaken within NextGRID are aimed at investigating the possibilities of integrating the AAA architecture in the overall NextGRID architecture and exploring the benefits of the synergy with other NextGRID architectural components, especially in the area of security1. The software - referred to as the AAA toolkit - can readily be downloaded by NextGRID partners to be used in a deployment scenario with their own (component) software. This document is part of the P4.7.3 reference component distribution, which includes, next to the AAA toolkit itself, a messaging client to send authorization requests to the AAA server, a simple web service (the Magic Eight Ball service), and a web-based access control component for the web service (a PEP). These components constitute a simple deployment scenario used as an illustration of the basic functionality of the toolkit and can possibly be used a basis for interested third parties to be modified, extended and used for their own purposes. Furthermore, the distribution includes the AAA toolkit source code files, the pre-built modules that can be deployed on a JBoss application server and a build script with which programmers can modify, rebuild and (re)deploy the AAA toolkit. Additionally, two articles are included in the distribution that describe the deployment in a network provisioning model [5] and a description of the AAA demonstration/experiment at iGrid 2005 [6] In section 2 of this document, an overview of the Generic AAA concepts and the AAA toolkit is provided. The generic AAA architecture consists of a rule-based engine (RBE) and application-specific modules (ASMs). Policies contain the rules that specify the conditions to reach a positive authorization decision, and they may contain call-outs to ASMs in order to obtain resource/service specific information or perform specific calculations, such as authentication, username-role mapping, or querying the status of network components. Section 3 describes the example deployment scenario mentioned above. It describes three scenarios in which a AAA server is typically deployed, as described in [1]: the agent sequence, the push sequence and the pull sequence. Section 4 contains the installation manual. It describes how to install the AAA server and the additional components such as the JBoss application server and the MySQL database. Section 5 contains the programmer's manual. In it, the policy language is explained, how policies should be constructed and inserted into the database, how to construct AAA requests, replies and schemas, and instructions to write ASMs. The programmer’s manual is intended to familiarize potential users with the toolkit and enable them to deploy it in their specific scenarios with a minimal amount of effort.

1 Note that this document is primarily intended to provide background information about the AAA toolkit, instructions for installing, deploying and programming it. This document does not provide an exhaustive overview of research efforts in which the toolkit was involved, nor every (exploratory) integration effort with other NextGRID components and its place in the NextGRID archtiecture.



Section 6 describes the recent AAA toolkit revised design. Along with developments in Grid computing and in the web services (WS) paradigm towards Service-Oriented Architectures (SOA), the AAA design now has a WSDL interface and several WS interoperability features. Section 7 provides a description of the deployment in the Supercomputing 2006 demonstrator, which comprised advance network resource reservation and scheduling in a GMPLS network, demonstrating the principles of Token-Based Networking (TBN). It also describes the integration with a security leveraging Intrusion Detection System (IDS) developed by NEC as part of a NextGRID collaboration between the UvA and NEC.



Table of Contents Glossary of Terms......................................................................................................................... 5 1 Introduction ................................................................................................................. 7 2 Generic AAA and the AAA Toolkit ............................................................................. 7 3 The AAA/Magic Eight Ball Demo............................................................................... 9 4 Installation Manual .................................................................................................... 15

4.1 Downloading the AAA toolkit – M8B demo tarball ..................................................... 15 4.2 Java Platform Standard Edition version 1.4.2 (J2SE).................................................... 16 4.3 Java Web Services Developer Pack.............................................................................. 16 4.4 MySQL........................................................................................................................ 18 4.5 Inserting the Policies into the AAA Database............................................................... 20 4.6 OpenLDAP.................................................................................................................. 21 4.7 Apache Web server...................................................................................................... 22 4.8 JBoss Application Server ............................................................................................. 22 4.9 The AAA Server, the M8B Service and the Web-Access Control Module.................... 24

5 Programmer’s Manual................................................................................................ 29 5.1 AAA Requests, the RBE, policies and ASMs Revisited ............................................... 29 5.2 Driving Policies: Policies for the M8B and SC05/VMTC Demo .................................. 31 5.3 Policy Language Syntax............................................................................................... 33 5.4 Defining a Policy, Constructing a Reply and Calling an ASM...................................... 34 5.5 Building the AAA Toolkit EAR................................................................................... 37

6 WSI Features ............................................................................................................. 38 6.1 Introduction ................................................................................................................. 38 6.2 The AAAXWS Module: WSDL and Message Processing ............................................ 39

6.2.1 Setting up the AAAXWS Module and AAAXWS Client........................................... 40 6.2.2 Structure of the AAAXWS Module and Message construction ............................... 41

6.3 Sample messaging scenarios ........................................................................................ 43 6.3.1 Sign and Encrypt Message, Static and Dyamic Policy Configuration ................... 43 6.3.2 SAML Authentication ........................................................................................... 51 6.3.3 Combined Scenario Runs ..................................................................................... 54

7 Interaction with Auxiliary Components: Network Resource Scheduling and Intrusion Detection .................................................................................................................................. 56

7.1 AAA Resource Scheduling and Reservation in Token Based Networks ....................... 56 7.2 AAA-IDS integration................................................................................................... 62

References ...................................................................................................................................... Appendix A: Using the JAAS Authentication ASM..................................................................... 70 Appendix B: Geronimo Java EE 5.0 Report Card ........................................................................ 72 Appendix C: XWS-Security Abstract Configuration File Schema................................................ 75

XWS-Security Configuration File Schema........................................................................... 75 Semantics of Security Configuration File Elements ............................................................. 79

Appendix D: Client output Sign/Encrypt Static Policy Configuration with Direct Certificate Key Reference .................................................................................................................................. 97 Appendix E: LDAP Attribute Lookup ....................................................................................... 103 Appendix F: SAML HOK Assertion.......................................................................................... 104 Appendix G: AAA Service WSDL............................................................................................ 108 Appendix H: NextGRID Experiment Plan ................................................................................. 112 Appendix I: AAA-IDS component testbed ................................................................................ 113



Glossary of Terms2 AAA: Authentication, Authorization, Accounting (pronounce: triple-a) AAA toolkit: An implementation of the design principles described in RFC 2604 (cf. [1]). AAA server: A running AAA toolkit, acting as a PDP or a PEP. Attack: An activity carried out against an information system which, if successful, can threaten and

potentially damage the assets of organizations that host or use the system. AuthN: An authentication process. AuthZ: An authorization decision from the AAA toolkit based on the evaluation of a driving policy

associated with a AAA request. ASM: An Application Specific Module. An ASM may be called by a the RBE if there are direction in the

Driving Policy tot do so, in order to interpret the semantics of attributes passed to it an return a simple value to reflect its result.

DIT: Directory Information Tree. The information stored in an LDAP database. DRAC: Nortel's Dynamic Resource Allocation Controller; a high-level network management system. Driving Policy: A policy, based on a simple if-then-else policy language, that is fetched by the RBE based

on the type of request message and that may call one or more ASMs Generalized Multi-Protocol Label Switching (GMPLS): A suite of protocol extensions to MPLS to make it

generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching (cf. [57]).

Grid: A system that is concerned with the integration, virtualization, and management of services and

resources in a distributed, heterogeneous environment that supports collection of users and resources (virtual organizations) across traditional administrative and organizational domains (real organizations).

Grid Service: A Web service that is designed to operate in a Grid environment, and meets the requirements

of the Grid(s) in which it participates. Grid Site: A node in a grid system, which is hosting resources and services. We say that something is local

(to a Grid Site), when it is operating within the administrative and organizational domain of a node. IDS: Intrusion Detection System. An IDS detects malicious activity, such as unauthorized access to

network and computing resources. IODEF: Incident Object Description and Exchange Format (IODEF, cf. [18]). A format to exchange

operational and statistical incident information, such as notifications of potential threats and system intrusions.

Label Switched Path (LSP): In MPLS networking, a LSP is a path through an MPLS network, set up by a

signaling protocol such as RSVP. LDAP: Lightweight Directory Access Protocol.

2 This limited glossary lists uncommon and/or frequently used terms in this document, for an extensive internet security glossary, cf. [19].



M8B: The Magic Eight Ball service; the example web service that is included in this distribution and for

which the AAA server acts as PDP and PEP. M8BWACM: The WAR file containing the controller servlet (PEP) for the M8B service. Multi-Protocol Label Switching (MLPS): A data-carrying mechanism which emulates some

properties of a circuit-switched network over a packet-switched network (cf. [54]). PBAC: Policy-Based Access Control. RBAC: Role-Based Access Control. RBE: Rule-Based Engine. The core of the AAA toolkit that processes policies and calls ASMs. Resource ReSerVation Protocol (RSVP): A resource reservation setup protocol designed for an integrated

services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties (cf. [56]).

PDP: Policy Decision Point. The PDP takes an AuthZ on the basis of a policy. PEP: Policy Enforcement Point. This is the entity that grants or denies access to a service or resource

depending on an AuthZ. RST: RequestSecurityToken. WS-Trust request message from a web service to a security token service. RSTR: RequestSecurityTokenResponse. WS-Trust response message from security token service to a web

service. STS: Security Token Service. Virtual Label Switch Router (VLSR): VLSR provides a mechanism to integrate non GMPLS equipment and

network regions into the end-to-end GMPLS provisioned services. VLSR translates standard GMPLS protocols into device specific protocols, to allow dynamic reconfiguration of non-GMPLS aware devices. The combination of a PC which runs the GMPLS based control plane software and the switch fabric is referred to as a VLSR (cf. [55]).

Viz: Used as synonym of “namely, precisely, that is to say”; from the Latin Videlicet (see

http://en.wikipedia.org/wiki/Viz) Web Service: A software system designed to support interoperable machine- or application-oriented

interaction over a network. A Web service has a WSDL interface and uses SOAP for its interactions. WSI: Web Service Interoperability. A set of specifications that promote interoperability, as specified by the

Web Services Interoperability organization (cf. [16]). WSS: Web Service Security. An OASIS standard for providing message-level integrity, confidentiality and

non-repudiation of SOAP messages (cf. [17]).



1 Introduction Authentication, Authorization and Accounting (AAA) are important concepts in Grid service and resource management. At the University of Amsterdam, a toolkit has been developed that implements the principles of the Generic AAA framework as laid down in RFC 2904 [1]. The efforts undertaken within NextGRID are aimed at investigating the possibilities of integrating the AAA architecture in the overall NextGRID architecture and exploring the benefits of the synergy with other NextGRID architectural components, especially in the area of security. This document provides an overview of the AAA toolkit (section 2), an installation manual (section 4) and a programmer's manual (section 5). As the NextGRID architecture evolves in the context of the OGSA framework [3] and the Web Services (WS) Architecture [4], this reference component includes, next to the AAA toolkit itself, a simple web service, and an access control component for the web service (a PEP). Section 6 describes recent extensions to the toolkit, which comprise WS-Interoperability components, to ground the AAA architecture further in the Service-Oriented Architectecture paradigm. Section 7 provides a description of the deployment in the Supercomputing 2006 demonstrator, which comprised advance network resource reservation and scheduling in a GMPLS network, demonstrating the principles of Token-Based Networking (TBN). It also describes the integration with a security leveraging Intrusion Detection System (IDS) developed by NEC as part of a NextGRID collaboration between the UvA and NEC. Additionally, two articles are included in this distribution3 that describe the deployment in a network provisioning model [5], and a description of the AAA demonstration/experiment at iGrid 2005 [6]. As will be discussed in section 3, the AAA toolkit is highly extensible and has already been deployed in various - mainly network provisioning - settings. Although the core distribution consisting of the core components, viz., the AAA front-end and the Rule-Based engine, and the documentation, viz., the installation and programmer’s manual, remains concise, this revised design contains elaborate material that describe deployment scenarios and server log listings that can be used for reference by potential users wishing to deploy the toolkit themselves.

2 Generic AAA and the AAA Toolkit

Authorizations may be represented by requests and associated policy based decisions resulting in a reply or action. In service and resource provisioning the components that take the authorization decisions (AuthZ) are usually known as Policy Decision Points (PDP). The components that actually provide access to the services and/or resources are known as Policy Enforcement Points (PEP). The AAA toolkit can fulfill both functions, which is illustrated by the setup of the Magic Eight Ball demo that ships with this distribution and is described in section 3.

3 In section 4 the structure of the package is discussed; extra material such as papers are in the directory AAAWSING/papers/ after uncompressing and unpacking the file in which this distribution is wrapped.



An authorization can be considered as a conditional right that shares a logical and semantic part. When exercised, this conditional right leads to a reply or action. In the Generic AAA framework, there is a separation of the logical and semantic parts. The goal of this separation is to allow logical communication of authorization decisions in a distributed fashion without considering the semantic details. The semantic details are transported to parts within a specific domain that understand them. The results of decisions taken in distinct domains constitute partial decisions (e.g., a positive or negative decision about the availability of a specific resource at the requested time), which can be transported along the domains, and combined by a formal (logical) method to render the overall, final authorization decision.

The diagram below depicts the basic concepts of Generic AAA. The inner part of he Generic AAA toolkit is called a Rules Based Engine (RBE) and consists of a generic part that is capable of processing policy rules that drive the system from a logical perspective. Application Specific Modules (ASMs) form the bridge between the internal logics and the semantic outside world. ASMs are capable of translating logical policy decisions into meaningful actions that interface with the outside world. In the other direction, ASMs translate meaningful states or events into conditions that are evaluated within a particular policy rule.

AAA requests are SOAP/XML messages; when received by the AAA server, the RBE fetches the driving policy and evaluates the request, effectively determining the workflow that will lead to a policy decision and corresponding policy actions. Policy actions may result in ASM calls, may drive outside events such as configuring network components, and will result in a reply to the user containing the AuthZ. ASMs may be present to call other PDPs, possibly other AAA servers, but not necessarily. These mechanisms will enable networks of AAA servers to evaluate a distributed set of policies. Driving policies may independently and autonomously be determined by individual administrative domains, thus enabling the creation of flexible multi-domain authorization scenarios.

Figure 1: The Generic AAA framework.



The Generic AAA toolkit comprises the following components:

• A front-end that receives the AAA messages (SOAP/XML), validates them against the corresponding schemas, parses the messages and forwards them to the RBE.

• The Rule Based Engine (RBE) uses a simple if-then-else and assignment grammar to

describe the evaluation of a driving policy as a result of receiving an AAA request message. The type of AAA request message will cause the RBE to fetch a corresponding driving policy. A driving policy consist of one or more policy conditions enclosed in the <if> clause and policy action enclosed in the <then> or <else> clause. The if-then-else grammar allows nesting. As such the RBE only handles the logical part of the policy decision. The semantics of a policy condition or policy action are handled by Application Specific Modules (ASMs).

• The ASMs are invoked from a policy that is executed in the RBE. ASMs typically yield

simple values that may be handed as arguments or values in a policy condition. The ASM is the only part that has awareness of the meaning of the handed arguments in the RBE invocation. Arguments may originate from the AAA request message or may originate from other ASMs or policy calculations.

The AAA Toolkit runs on a J2EE Application Server, viz., JBoss 4 [8]. We discuss the implementation details along with the Magic Eight Ball (M8B) demo setup in the next section.

3 The AAA/Magic Eight Ball Demo In Figure 1 the user and the components present in the reference component distribution are depicted. For installation instructions, see section 15.

AAAUser

JSP

Input/outputpage

serverAAA

server Service

M8B

WAC

M8B WA Controller (WM)AAA ClientAAA RequestM8B Caller

AAA Server (WM)RBE (EJB)AAAReplyM8B Caller

M8Ball (EJB)

Figure 2: Components in the distribution.



The left-hand boxes depict the PEP which is implemented as a controller servlet (in line with the MVC or Model-2 architecture, cf. [9]). The controller presents the user JSP pages according to the model or authorization setup he wishes to use for accessing M8B. For a description of the models (agent/push/pull) see section 3 below and [1]. The controller gathers the data from the user, obtains an AuthZ and takes the appropriate action. The classes are packaged in a web module - the M8B Web Access Controller Module - and consist of the following components:

• M8B Web Access Controller (M8BWAC): A standard HTTP servlet that implements (technically: extends) the doGet and doPost methods according to the input of the user. It instantiates the AAAclient class according to the model chosen by the user.

• AAA Client: This class creates a AAA request according to the input of the user and sends it to the AAA server.

• AAA Request: A utility class for creating a AAA request. It uses JAXB (Java Architecture for XML Binding) [10] to create a request from an XML schema (the java sources are first obtained from the request schema with the xjc binding compiler).

• M8B Caller: A client that calls the M8B service (technically: a dynamic proxy client4). • JSP pages: The pages with forms to collect user data which is sent to the M8BWAC.

The box in the middle represents the AAA toolkit and is packaged in a web module (AAAWM5); the main components are:

• AAA Server: This is the front-end of the server. In this distribution there are two versions of the AAA Server: the first is implemented as a JAXM (Java API for XML Messaging) servlet [11], the second is implemented as a web service endpoint. The latter is discussed in more detail in section 6. Clients can send AAA requests (XML/SOAP) by creating a point-to-point connection to the AAA Server and sending the message directly in line with the request-response model. The AAA Server validates the request, parses it and sends it to the RBE.

• RBE: The RBE (described in section 2), is implemented as a Java Enterprise Bean (EJB). It processes the policy that corresponds with the type of the AAA request received and makes call-outs to ASMs if the policy requires it to do so. After processing the policy, it creates a reply that is constructed using the reply class name that corresponds to the type of the AAA request (this is specified in the policy database).

• AAA Reply: This utility class itself is abstract; there should be a derived class for every type of AAA request. The derived class processes the classes that are derived from the reply schema that corresponds to the AAA request. We illustrate this mechanism below.

• M8B Caller: A client that calls the M8B service (technically: a dynamic proxy client).

The M8B web service is implemented as an EJB with just one method (askQuestion) that randomly returns one of these strings (in response to a 'question of life' [12]):

• Outlook Good • Outlook Not So Good • My Reply Is No

4 A dynamic proxy client is a web-service client that is independent of the implementation of the web service (as opposed to a static-stub client). 5 In this (revised) version, there is an additional Web Module (AAAXWS) that handles web service based requests. This component is discussed in section 6.



• Don't Count On It • You May Rely On It • Ask Again Later • Most Likely • Cannot Predict Now • Yes • Yes Definitely • Better Not Tell You Now • It Is Certain • Very Doubtful • It Is Decidedly So • Concentrate and Ask Again • Signs Point to Yes • My Sources Say No • Without a Doubt • Reply Hazy, Try Again • As I See It, Yes

In AAAWSING/M8B2ClientPackage/ there is a client to access the M8B service directly (the contents of the distribution will be discussed more elaborately in section 4). After making the proper modifications to the build.xml ant script (see the installation manual, section 4, for directions on how to install ant), the service can be accessed directly, i.e., without intervention by the AAA Server. The client code is used in an ASM that enables the AAA Server to call the M8B service. In Figure 3, the workflow that is described above is depicted. Note that the authentication service is not present in this distribution (for reasons mentioned above). Authentication in the AAA/M8B setup is done through a simple check in the policy (see Section 5).

Figure 3: AAA/M8B demo workflow.

In the directory AAAWSING/AAAWMClient/ there is a AAA messaging client present, with which AAA requests to access the M8B service can be sent. Section 4 and 5 explain how to install and run the AAA/M8B demo, but to clarify the workflow depicted above, the relation between the requests, the schemas, the policies and replies are summarized in the table below together with their locations.

RBE

M8B AAA

Front- end

User

RADIUS RADIUS

service

service M8B authent

authorz ASM

ASM Policy

Repository

2 3 4

12

1

5

6

7

8

10 11

9



Table 1: Relation between the M8B service AAA requests, the request schemas, the policies and the reply schemas. AAA Request AAA Request

schema Policy Reply Schema

AAAWSING/AAAWMClient/ Web Server and AAAWSING/AAA/

AAAWSING/AAA/PolicyMng/ Web Server and AAAWSING/AAA/

AAAWSING/AAAXWSClient/ Web Server and AAAWSING/AAA/

AAAWSING/AAA/PolicyMng/ Web Server and AAAWSING/AAA/

AAAM8BAGENT.xml AAAM8B.xsd AAAM8B.policy AAAReplyM8B.xsd

AAAM8BPushReqT.xml AAAM8B.xsd AAAM8BPushReqT.policy AAAReplyM8B.xsd

AAAM8BPushToken.xml AAAM8B.xsd AAAM8BPushToken.policy AAAReplyM8B.xsd

AAAM8BPull.xml AAAM8B.xsd AAAM8BPull.policy AAAReplyM8B.xsd

Step 1 of the workflow in Figure 3 involves sending one of the AAA Requests listed in the table to the AAA Server. The requests are validated against the AAA Request schema and sent to the RBE. The corresponding policy listed in the table under 'Policy' is fetched (steps 2 and 3), and if the AuthN checks out, the M8B service is accessed (9 and 10). The response from the M8B ASM is received by the RBE (step 11) and processed with the classes derived from the Reply schema and sent back to the user (step 12). In the workflow diagram above, a specific model or message sequence is depicted in the sense of RFC 2903 and 2904 [1], [2], viz. the agent model. In the agent model, the AAA Server acts both as a PDP and a PEP at the same time; it authorizes the user, and it provides access to the service. Below we give an overview of all three models as applied in the AAA/M8B demo6.

1. The Agent Model In Figure 1 below, a simplified version of the picture above is depicted, i.e., a representation of the interaction between the user, AAA and the M8B service, with the JSP page as an intermediary that creates the xml message passed to AAA. The AAA front-end is mainly a message receiver and a filter to validate the sent message by parsing it, using the AAA XML message schema for the M8B service. Below is a more schematic representation of the picture above that will be used to indicate the differences with the other two models, viz., the pull and the push model.

6 The emphasis here is on the M8B demo workflow, i.e., the flow of the messages and processing that happens when running the demo. In later sections, most notably section 5, the message formats (e.g., the requests) and processing (e.g., authentication) are discussed further.



Figure 4: The Agent Model.

2. The Pull Model In the pull-model the user is taken to the JSP page on which he can ask his question. The controller keeps track of the session and whether the user is authenticated and authorized to access the M8B service. Initially, the user is, of course, not authenticated/authorized, and he is taken to the authentication JSP page. The data is checked and if it is correct the user is again forwarded to the 'question page', but now in the authenticated state. The reason this is called a pull-model, is that the authorization is pulled from the AAA server by the PEP (and not provided with the request). It is depicted below.



Figure 5: The Pull Model.

3. The Push Model. In the push model, the user interacts with AAA and the (M8B) service separately. He first contacts AAA to obtain an access token that proves he can access the desired service. Subsequently he contacts the service with the token and then gains access to it, if the token is recognized as valid. The service may contact AAA for additional validation. The reason this is called a push model, is that the user pushes the authorization obtained from the AAA server onto the M8B service to gain access.



Figure 6: The Push Model.

The next section contains detailed instructions for installing the AAA Server, the M8B demo and necessary components. The installation procedure reveals more details about the structure and mechanisms of the AAA server and the M8B demo setup. In the programmer's manual, still more details are explained which should enable the reader to write his own ASMs and policies with which he can deploy the AAA Server in his own setup.

4 Installation Manual

4.1 Downloading the AAA toolkit – M8B demo tarball The installation of the AAA toolkit and the Magic Eight Ball demo will be explained later, but because there is a set of libraries packaged with the toolkit that need to be installed together with the JBoss application server, the package should be downloaded first. The steps explained in this section should be used as guidelines. The platform used here is Red Hat 9 running on a Dell Poweredge 1750 with four Xeon cores; the steps below and the way they should be executed differ



per platform and system setup (the author has successfully tested the setup on Windows XP and Mac OS X). Go to the BSCW server, and download the tarball: http://www.nextgrid.org/bscw/bscw.cgi/0/2620/AAAWSING.tgz Unpack it: >tar xvfz AAAWSING.tgz This is high-level the directory structure AAAWSING/AAA The AAA toolkit AAAWSING/M8B The M8B demo service AAAWSING/M8BWACM The web-access controller for the M8B service AAAWSING/shared-libs The required libraries for the AAA toolkit AAAWSING/ids-libs The required libraries for AAA-IDS messaging AAAWSING/AAAWMClient A messaging client to send AAA request messages to the AAA

server, using a JAXM endpoint using no transport- or message-level security.

AAAWSING/AAAXWSClient A messaging client to send AAA request messages to the AAA server, using a WSDL endpoint with configurable/customizable transport- or message-level security.

AAAWSING/M8B2ClientPackage A dynamic proxy client for the M8B service

4.2 Java Platform Standard Edition version 1.4.2 (J2SE) The AAA toolkit uses the Java 2 platform together with the JBoss application server (see paragraph 4.8) to run on. At the time of this writing, version 1.4.2_12 was available at: http://java.sun.com/j2se/1.4.2/download.html Download the version appropriate for your platform. On Linux i586 platforms download j2sdk-1_4_2_12-linux-i586-rpm.bin. To extract and install as root user: >chmod u+x j2sdk-1_4_2_12-linux-i586-rpm.bin >./ j2sdk-1_4_2_12-linux-i586-rpm.bin >rpm -i j2sdk-1_4_2_12-linux-i586-rpm.bin This installs java in /usr/java j2sdk1.4.2_12. Make sure to include the bin subdirectory in your path.

4.3 Java Web Services Developer Pack



The AAA toolkit requires a number of libraries that are not in the standard distribution of the JBoss application server on which it runs. On the AAA toolkit web page [7] all necessary libraries can be downloaded and installed as explained below, however, most of them can also be downloaded from their original distributors although sometimes specific versions are required. Because compiling, deploying and running the AAA toolkit requires tools like ant we recommend downloading and installing the Java Web Services Developer Pack, version 1.5 (JWSDP 1.5) that can be found on: http://java.sun.com/webservices/downloads/1.5/index.html This is an older version of JWSDP; 1.6 is the last version that is compatible with J2SE, but the XML parsers of JWSDP 1.6 are incompatible with the DOM interfaces the AAA toolkit uses. The installer either has a GUI or can be run from the command line and presents a number of options, most of which are straightforward. Some of the more advanced choices are shown below. ------------------------------------------------------------------------------- Select a Web Container Please select the Web container option you would like to integrate this product on. Suitable Web containers for this product are: Sun Java System Application Server Platform Edition 8.0, Sun Java System Web Server 6.1, or Tomcat 5.0 for Java WSDP Note: Certain technologies, including JSTL and the Java WSDP Registry Server require a Web container. Note: If you do not have a suitable Web container installed you may download one at: http://java.sun.com/webservices/containers Available Web Container Options: 1. No Web Container 2. Add a Suitable Web Container installation To select an item enter its number [1] 1 ------------------------------------------------------------------------------- [X] 1 - Typical Choose this option to install the default configuration. Recommended for most users. [ ] 2 - Custom Choose this option to select specific technologies to install. Recommended for advanced users. To select an item enter its number, or 0 when you are finished: [0] 1 ------------------------------------------------------------------------------- Set HTTP Proxy Information This product allows you to connect to the Internet using an HTTP proxy. Please enter the following information to enable connectivity to the Internet:



[ ] 1 - Use a proxy server for your HTTP connections [X] 2 - Not use a proxy server for your HTTP connections To select an item enter its number, or 0 when you are finished [0]: 2 Include <installation directory>/jwsdp-1.5/apache-ant/bin in your path.

4.4 MySQL MySQL is used as the database for the policies that reside in the policy repository (AAAWSING/AAA/PolicyMng) and are used by the AAA toolkit. It can be downloaded from: http://www.mysql.com The Windows version is quite intuitive to complete, but the Linux version is somewhat trickier. We will go into the Linux procedure (the tarball version, not the rpm version) somewhat deeper now. When downloaded, it needs to be unpacked to view the installation instructions, but according to the instructions the tarball is recommended to be installed in a specific place in a specific way (because, e.g., automatic startup scripts assume the installation is there); this works if you have a version of gunzip and tar installed on your system/what is referred to here as FULL-PATH-TO-MYSQL-VERSION-OS is the directory in which you downloaded the MySQL tarball: > cd /usr/local > gunzip < /PATH/TO/MYSQL-VERSION-OS.tar.gz | tar xvf - > ln -s FULL-PATH-TO-MYSQL-VERSION-OS mysql If you follow these instructions, there will be a link 'mysql' in the /usr/local directory; at that location will be the full instructions to install MySQL (/usr/local/mysql/INSTALL_BINARY). If you followed the instructions, the mysql server is now running and you will have to perform some post-installation procedures, of which we will describe the minimum here; for the full documentation see the MySQL website (http://dev.mysql.com/doc/) in particular chapter 2 for post-installation (e.g., for automatic startup of the server, see paragraph 2.9.2.2) and subchapter 5.8 for user management (we encountered some problems with the literal commands given in the reference manual; we used the minimum set of instructions given below). First set a password for the superuser (replace 'password' in the example below for your own password): > mysql -u root -p mysql> set password for root@localhost = password('password'); Query OK, 0 rows affected (0.00 sec) Initially, there are some accounts present in the database, including an anonymous account. We assume there is no need for this if used in conjunction with the AAA toolkit. There are is also a database present for testing purposes. To remove the anonymous account and the test database: mysql> show databases;



+--------------------+ | Database | +--------------------+ | information_schema | | mysql | | test | +--------------------+ 3 rows in set (0.00 sec) mysql> drop database test; Query OK, 0 rows affected (0.01 sec) mysql> delete from mysql.user where user = ''; Query OK, 2 rows affected (0.00 sec) mysql> flush privileges; Query OK, 0 rows affected (0.00 sec) Now we can create a policy database, which we name AAA, create the policies table, and the user with password that the AAA toolkit uses to access the database. >mysql> create database AAA; Query OK, 1 row affected (0.01 sec) mysql> grant all privileges on *.* to monty@localhost identified by 'kip123' with grant option; Query OK, 0 rows affected (0.00 sec) mysql> use AAA; Database changed mysql> create table policies ( name varchar(20), replyclass varchar(20), policy MEDIUMBLOB); Query OK, 0 rows affected (0.01 sec) Run the following commands to check if the commands have succeeded: mysql> show tables; +---------------+ | Tables_in_AAA | +---------------+ | policies | +---------------+ 1 row in set (0.00 sec) mysql> describe policies;



+------------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+-------------+------+-----+---------+-------+ | name | varchar(20) | YES | | NULL | | | replyclass | varchar(20) | YES | | NULL | | | policy | mediumblob | YES | | NULL | | +------------+-------------+------+-----+---------+-------+ 3 rows in set (0.00 sec) We are now ready to fill the AAA database with the policies necessary for the Magic Eight Ball demo (the meaning of the fields and of the policies will be explained in the Programmer's Manual).

4.5 Inserting the Policies into the AAA Database In the main AAA toolkit/Magic Eight Ball distribution there is a policy management directory: AAA/PolicyMng that contains four policies to handle the AAA requests from the user and the PEP. The role of the policies, their syntax and compilation procedure is described in section 5. The policies are pre-compiled and can be added to the database, with a simple database management program (DBmngr.java). Any deviations of the installation of the policies database as shown above (like the database URL; the database is accessed by the RBE, this name is hardcoded as “AAA”) should be reflected in the code, which should then be recompiled. The policy languae is explained in section 5.3, the policies used for the M8B demo and should be inserted in the database is as follows (they are in the directory AAAWSING/AAA/PolicyMng): AAAM8B.policy AAAM8BPull.policy AAAM8BPushReqT.policy AAAM8BPushToken.policy To insert them, they need to be serialized, which can be done with the genPolicy tool present in the AAAWSING/AAA/PolicyMng directory, and renders *.spo counterparts of the policy files. For the policies above, the serialized versions are already there, and can be inserted in the database as described below. Invoking the policy-management program has the following format7: >java DBmng x <policy-name> <reply-class> where x = {1=insert, 2=read, 3=delete} Below is illustrated how this works for the policy that handles token requests: the AAA/Magic Eight Ball Request Token policy (AAAM8BReqT.policy). The procedure for the other policies is the same. 7 Both the source code as well as the compiled version of the DBmngr class is present. Compilation and usage, as always, depend on a working Java installation and correct classpath setting.



>java DBmngr 1 AAAM8B AAAReplyM8B Using> 1=insert ; 2=read ; 3=delete AAAM8B connection INSERT INTO policies (name,replyclass,policy) VALUES('AAAM8B', 'AAAReplyM8B', ?) Database(insert): File = AAAM8B.spo[size=1323] >java DBmngr 2 AAAM8B Using> 1=insert ; 2=read ; 3=delete AAAM8B connection test policy obj Found a result... Object is alive! Note: In some J2SE versions there is an issue with IPv6 addresses. To be sure that only IPv4 addresses are used add the option: -Djava.net.preferIPv4Stack=true

4.6 OpenLDAP The Lightweight Directory Access Protocol is widely used for the storage of directories that contain data such as user names, passwords and permissions. The AAA toolkit uses LDAP to store known AAA clients (or requestors) and data associated with them. Most operating systems come with a version of LDAP, the version; in this distrubution OpenLDAP (cf. [44]) is used. Because LDAP is common and well documented (a few pointers: [45][46]), we suffice by providing the configuration file (slapd.conf) and a file containing a minimal set of directory entries (aaa.ldif): $HOME/AAAWSING/AAA/var/slapd.conf $HOME/AAAWSING/AAA/var/aaa.ldif It is also recommended to use a visual browser (cf. [47]), to view the data in the ‘Directory Information Tree’ (DIT). Below is a representation of the data in aaa.ldif, in such a visual browser. It contains two AAA clients, and an entry that groups the clients that are allowed to use X.509 certificates as a means of authentication. In section 6.3 some WSI messaging scenarios are discussed in which this DIT is used.



Figure 7: A visual representation of the AAA users and grouping DIT.

4.7 Apache Web server The apache web server can be downloaded here: http://httpd.apache.org/download.cgi On Windows you can use the installer, this is straightforward. On Linux the source has to be downloaded, compiled and installed, which is more work, but usually also straightforward. The instructions can be found on http://httpd.apache.org/docs/2.2/install.html Copy the schema files in the AAA directory to the web server (on Linux): >cp AAAM8B.xsd /var/www/html/ >cp AAAReplyM8B.xsd /var/www/html/ You should be able to view both schema files from a browser: http://<IP address/hostname or your machine>/AAAM8B.xsd http://<IP address/hostname or your machine>/AAAReplyM8B.xsd

4.8 JBoss Application Server The AAA toolkit runs on the JBoss application server version 4.0.3SP1. Previous and later versions have been known to cause problems because of incompatibility between libraries the AAA toolkit needs (and need to be installed in the server) and JBoss libraries.



http://labs.jboss.com/portal/jbossas/download Run the installer: java -jar jboss-4.0.3SP1-installer.jar This opens up a dialogue box with options. When choosing a J2EE profile, choose "default", and choose an admin username/password in the JMX Security dialogue box. The directory just above jboss-4.0.3SP1 and AAAWSING is designated $HOME. Copy the library files in AAAWSING/shared-libs/ and in AAAWSING/ids-libs/ to the JBoss library directory and the packaged endorsed libraries to the JBoss endorsed directory8: > cp xtraendorsedlibs.tgz $HOME/jboss-4.0.3SP1/lib/endorsed/ > cd $HOME/jboss-4.0.3SP1/server/default/lib/endorsed/ > tar xvfz xtraendorsedlibs.tgz > rm xtraendorsedlibs.tgz > cd $HOME/AAAWSING/shared-libs/ > cp ./*.jar $HOME/jboss-4.0.3SP1/server/default/lib/ > cd $HOME/AAAWSING/ids-libs/ > cp ./*.jar $HOME/jboss-4.0.3SP1/server/default/lib/ Also, unpack the library tarballs in the shared-libs directory. In the ant build scripts the references to the library directory is shared-libs. A possible alternative to using the shared-libs directory is to modify the build scripts to refer to the JBoss directories so that the libraries in the shared-libs directory can be removed (and free up disk space). Try to make sure the existing libraries are overwritten (compare some of the libraries like xalan.jar with those in the tarball; to get the list of the content of the tarball execute the command tar –tvfz xtraendorsedlibs.jar). In some cases it is necessary to make some of the Tomcat libraries available through the $HOME/jboss-4.0.3SP1/server/default/lib/ directory: > ln -s ../deploy/jbossweb-tomcat55.sar/commons-el.jar > ln -s ../deploy/jbossweb-tomcat55.sar/jasper-compiler > ln -s ../deploy/jbossweb-tomcat55.sar/jasper-compiler.jar

8 As was mentioned section 4.3, errors may occur when processing, generating and validating XML content as a result of incompatibilities between JWSDP library versions, Java versions, the libraries in the classpath, the version of ant used etc. If problems of this kind occur, it is recommended that alternative versions of these libraries (especially the Xalan and Xerces libraries) are installed in the JBoss library and AAAWSING/shared-libs directory until a working configuration has established. The underlying problem is that JAXP implementations of the specifications used (such as DOM) may differ, libraries may inconspicuously implement specifications of different versions of the specifications and they sometimes simply have bugs in them (cf. e.g., [58], [59]).



> ln -s ../deploy/jbossweb-tomcat55.sar/jasper-compiler-jdt.jar > ln -s ../deploy/jbossweb-tomcat55.sar/jasper-runtime.jar > rm jboss-saaj.jar There is an entry in: $HOME/jboss-4.0.3SP1/server/default/deploy/jbossweb-tomcat55.sar/conf/web.xml that may cause problems because the directory that is referred to there (conf/tlds) is not present in the standard distribution. Edit web.xml and delete the following entry: <init-param> <param-name>engineOptionsClass</param-name> <param-value>org.jboss.web.tomcat.tc5.jasper.JspServletOptions</param-value> </init-param> As was mentioned in section 4.5, in some J2SE versions there is an issue with IPv6 addresses. To be sure that only IPv4 addresses are used by the VM the JBoss server is running on, edit the JBoss startup script run.bat for Windows or run.sh on UNIX: > emacs $HOME/jboss-4.0.3SP1/bin/run.sh Change JAVA_OPTS: # Setup JBoss sepecific properties JAVA_OPTS="$JAVA_OPTS -Dprogram.name=$PROGNAME -Djava.net.preferIPv4Stack=true"

4.9 The AAA Server, the M8B Service and the Web-Access Control Module The installation is now almost complete. This AAA distribution comes with a web service, i.e., the Magic Eight Ball service, and a Web Access Controller (the PEP), which are now ready for deployment on the JBoss application server. For more information on the internals of the modules and how they work together, see the Programmers Manual (section 5). To deploy the M8B service (we assume you unpacked AAAWSING.tgz in your home directory $HOME), first start the JBoss server: > $HOME/jboss-4.0.3SP1/bin/run.sh In the terminal where you started the server logging messages are displayed. You should see the server start up without any error messages. If you want the server to be detached from the terminal window you started the server in, use the arguments >&1& after the command above. Now open a new terminal and copy the module files to the JBoss deployment directory: > cp $HOME/AAAWSING/M8B/M8BM.jar $HOME/jboss-4.0.3SP1/server/default/deploy/ > cp $HOME/AAAWSING/M8BWebAccess/M8BMWACM.war $HOME/jboss-4.0.3SP1/server/default/deploy/



> cp $HOME/AAAWSING/AAA/AAAServer/AAAServer.ear $HOME/jboss-4.0.3SP1/server/default/deploy/ After each module is copied, you should see logging messages from the server that each module is started. The output should be similar to this: 13:34:23,437 INFO [EjbModule] Deploying M8BallBean 13:34:23,703 INFO [EJBDeployer] Deployed: file:/D:/jboss-4.0.3SP1/server/default/deploy/M8BM.jar 13:34:24,000 INFO [WSDLFilePublisher] WSDL published to: file:/D:/jboss-4.0.3SP1/server/default/data/wsdl/M8BM.jar/M8BallBean.wsdl 13:34:24,187 INFO [AxisService] WSDD published to: D:\jboss-4.0.3SP1\server\def ault\data\wsdl\M8BM.jar\M8BallPort.wsdd 13:34:24,875 INFO [AxisService] Web Service deployed: http://cracker:8080/M8BM/M8BallBean 13:34:24,937 INFO [TomcatDeployer] deploy, ctxPath=/M8BM, warUrl=.../tmp/deploy /M8BM.jar-ws33476.war/ 13:34:45,609 INFO [TomcatDeployer] deploy, ctxPath=/M8BWACM, warUrl=.../tmp/dep loy/tmp33477M8BWACM-exp.war/ 13:34:45,906 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/ 13:34:46,234 INFO [EARDeployer] Init J2EE application: file:/D:/jboss-4.0.3SP1/ server/default/deploy/AAAServer.ear 13:34:47,140 INFO [EjbModule] Deploying RBEEJB 13:34:47,171 INFO [EjbModule] Deploying M8BCallerBean 13:34:47,296 INFO [ProxyFactory] Bound EJB Home 'RBEEJB' to jndi 'ejb/RBE' 13:34:47,312 INFO [ProxyFactory] Bound EJB Home 'M8BCallerBean' to jndi 'M8BCallerBean' 13:34:47,328 INFO [EJBDeployer] Deployed: file:/D:/jboss-4.0.3SP1/server/default/tmp/deploy/tmp33478AAAServer.ear-contents/ASM.jar 13:34:47,343 INFO [TomcatDeployer] deploy, ctxPath=/AAAWM, warUrl=.../tmp/deploy/tmp33478AAAServer.ear-contents/AAAWM-exp.war/ 13:34:47,484 INFO [EARDeployer] Started J2EE application: file:/D:/jboss-4.0.3SP1/server/default/deploy/AAAServer.ear In the distribution a M8B web service client is included that can be used to test whether the service is running properly9. The client can be run with ant; the invocation and output should look similar to the following: [username@host M8B2ClientPackage]$ ant run-client Buildfile: build.xml

compile: [javac] Compiling 1 source file to AAAWSING/M8B2ClientPackage/output/classes

run-client: [echo] Now running client... [echo] [java] Now creating a dummy M8Ball object... [java] Contacting webservice at http://localhost:8080/M8BM/M8BallBean?wsdl [java] The answer to your question 'Can I have access running ant?' is:

9 As was discussed in section 3, the M8B service simply returns one out of twenty strings randomly.



[java] As I See It, Yes

BUILD SUCCESSFUL Total time: 4 seconds

Two messaging clients are included with which it is possible to send AAA request messages directly to the AAA server. The first client calls the JAXM endpoint, the other one the WS endpoint; here we discuss the former, the latter is discussed in section 6. You can use this client to see if the modules are properly installed and working. There are four requests in the directory of the messaging client ($HOME/AAAWSING/AAAWMClient):

• AAAM8BAGENT.xml; for the agent model. This request should contain authentication data and the M8B question.

• AAAM8BPushReqT.xml; for the push model requesting a token. This request contains authentication data.

• AAAM8BPushToken.xml; for the push model using a token. This request contains the token and the M8B question.

• AAAM8BPull.xml; for the pull model. This request contains authentication data. Access to the M8B service will be provided by the PEP.

Each of these messages can be sent to this AAA server, below the AAA request containing authentication data and a service operation on the M8B service is sent: >ant run -Dxml-file=AAAM8BAGENT.xml -Dhost=localhost -Dport=8080 -Dendpoint=AAAWM/AAAServer Buildfile: build.xml init: prepare: build: run: [echo] Running... [java] Arguments > ant run -Dxml-file=<xml file> -Dhost=<ip> -Dport=<server-port> -Dendpoint=<service-endpoint> [java] message created, sending.. [java] This is the endpoint: http://localhost:8080/AAAWM/AAAServer [java] Name is AAAReply [java] Attribute name is type [java] Attribute value is AAAM8B [java] Attribute name is version [java] Attribute value is 0.1 [java] Attribute name is xmlns [java] Attribute value is http://www.AAA.org/ns/AAAReply [java] Attribute name is xsi:schemaLocation [java] Attribute value is http://www.AAA.org/ns/AAAReply http://localhost/AAAReplyM8B.xsd [java] Name is AAA [java] Name is Message [java] Content is: permit [java] Name is M8B



[java] Name is m8bresponse [java] Content is: Concentrate and Ask Again BUILD SUCCESSFUL Total time: 4 seconds

In the terminal window you used to start the JBoss server, you should be able to see how AAA processes the request and contacts the M8B service. The output above is a parsed message from AAA to the messaging client. If this works for all the messages, the AAA toolkit and the M8B service are installed successfully. To test whether the Web Access Control Module (M8BWACM) is correctly installed, open a browser window and go to the following URL: http://localhost:8080/M8BWACM/controller?action=AGENT



The page that is displayed looks like this:

AGENT Sequence In this model the Magic Eight Ball Service is invoked through the AAA server. This means that the user should send the AAA server a AAA request, with the appropriate authentication data. This JSP page generates a AAA Request message by means of a AAA client that is running on the JSP page's application server. If you fill out the form below you can see either the XML code that is sent to the AAA server, or you can directly send the request without viewing it first. This is the sequence of what happens when you send the AAA request:

1. This application generates a AAA request and sends the request to the AAA server 2. The AAA server receives the request, tries to authenticate you and if you are authenticated,

the AAA server sends your question to the Magic Eight Ball service, otherwise it returns a 'deny' message

3. The Magic Eight Ball service returns the answer to your question, sends it back to the AAA server, which, in turn sends it back to this application

4. This application displays the authorization decision and the answer of the Magic Eight Ball service and the parsed XML reply of the AAA server

Your question: AAA specifics :

Method :

Username:

Password:

Realm :

View AAARequest

Submit AAARequest without viewing Submit



no-msg-yet

Figure 8: JSP page displayed by the M8B controller for the Agent model. From the data filled out by the user a AAA request is produced and sent to the AAA Server.

This is a JSP page, that creates a AAA request from the input given in the form fields. Test if it is working by filling in:

1) Your question=Does my installation work? (or anything else) 2) Method=radius (or anything else) 3) User=kip 4) Password=monty 5) Domain=fff (or anything else) 6) Tick the radio button “Submit AAARequest without viewing”

And press “Submit”. The M8BWACM now constructs a AAARequest and submits it to the AAA server in the same way as the messaging client. You should now see output in the text field that is similar (depending how you fill in the form fields) to the output from the messaging client. Check if this works for the other models (action=PUSH and action=PULL); and if it does, the installation is successful.

5 Programmer’s Manual

5.1 AAA Requests, the RBE, policies and ASMs Revisited In section 2 the general architecture of the AAA toolkit was explained, and the relation between AAA requests, policies, ASMs and replies was discussed in section 3 by means of the M8B demo. To recapitulate: AAA requests are authorization requests that refer to a method of authorization by means of their type (the schema of the request) and contain the details on the basis of which a decision is made. The method of authorization is contained in a policy: a set of if-then-else rules that is evaluated by the Rule-Based Engine (RBE). Conditions in a policy can either be satisfied by



the information contained in the request, or by the outcome of a computation involving an external component, viz., an Application Specific Module (ASM). Additionally, the RBE can perform actions specified in the policy, i.e., instead of perfoming an evaluation on which the final authorization decision depends (such as granting acces to the M8B service), it can access the M8B service itself and fetch the answer on behalf of the requestor. In the M8B scenario the AAA server returns the answer to the requestor along with the authorization decision (this constitutes the Agent Model). As will be explained in section 5.4, the AAA request and the policy for the M8B demo is very simple and can serve as a template for writing custom policies and ASMs. Because ASMs can literally contain any type of computation and call-outs to other components anywhere, there are no rules for writing ASMs. For instance, there can be an ASM that authenticates the requestor according to information that is provided in the AAA request (which is not the case if the policy discussed in section 5.4 is inserted into the database; in the case discussed there, the authentication is done by the RBE itself). To further illustrate this process, if we examine the policy that is in the current distribution: AAAWSING/AAA/PolicyMng/AAAM8B.policy

the first rule is as follows: if (ASMsb::AuthNJAASBean.authN (Request::AAA.Authentication.simple.username, Request::AAA.Authentication.simple.password) )

This refers to an ASM named AuthNJAASBean. and calls the method authN with two parameters: username and password. The value of these parameters are in the AAA request that can be found here: AAAWSING/AAAWMClient/AAAM8BAGENT.xml

As you can see, the type of the request is AAAM8B and it contains the elements: <AAA><Authentication><simple><username>

<AAA><Authentication><simple><password>

In order to find an ASM that is stated in the policy, the RBE (AAAWSING/AAA/src/rbe/RBEEJB.java), performs a JNDI lookup for an EJB, including its method(s), using the name in ASMsb::<name>.<method> This is done in the RBE method evaluateProcedure:

Context initial = new InitialContext(); Object objRef = initial.lookup(ASMBeanName); System.out.println(" found ASM >>"); EJBHome ASMhome = (EJBHome) PortableRemoteObject.narrow(objRef, EJBHome.class); Method createMethod = ASMhome.getClass().getMethod("create", null); Object theOBJ = createMethod.invoke(ASMhome, new Object[0]); Method[] listSJB = theOBJ.getClass().getMethods();



In this case, an EJB called AuthNJAASBean should be present, and its remote interface should contain a method AuthN taking two arguments. The remote interface can be found here: AAAWSING/AAA/src/authnjaas/AuhtNJAAS.java

In sum, writing an ASM consists of nothing more than writing an EJB (which can be as simple as the M8B ASM, or as complex as a scheduler or resource manager), specifiying its methods in the remote interface and editing the deployment descriptors of the ASM EJB module accordingly. To use it, a schema for the the request should be written, put on the web server where the AAA server looks for the schema to verify the requests, a policy should be written specifying how to use and to call the ASM, and a reply class and schema should be written that construct the reply sent back to the user. The deployment descriptors for the ASM module can be found here: AAAWSING/AAA/ASM/META-INF

5.2 Driving Policies: Policies for the M8B and SC05/VMTC Demo The AAA toolkit policy repository can be found in AAAWSING/AAA/PolicyMng along with a tool (genPolicy) to generate serialized policy objects and a tool for managing policies in the policy database. In section 4.5 instructions are given to insert and remove policies from the MySQL database. Note that genPolicy may have to be modified to include the current directory as the classpath. To generate a serialize policy object: > genPolicy AAAM8B Note that the extension of the file AAAM8B.policy has to be left out. The database manager DBmngr can be modified and compiled from the command line, provided that the current directory is in the classpath. In the repository the following policies are present to run the M8B demo (for a M8B demo scenario walkthrough, see section 3): AAAM8B.policy The policy for the Agent model AAAM8BPushReqT.policy The policy for the Push model when a token is requested AAAM8BPushReqT.policy The policy for the Push model when a token is used AAAM8BPull.policy The policy for the Pull model In the directory AAAWSING/AAA/PolicyMng/example_policies a number of policies can be found that were being used for other purposes than the M8B demo, and may be of assistance when constructing your own policies. The policies that were used for the iGrid 2005 demo and are described in [6] are in the directory AAAWSING/AAA/PolicyMng/igrid_files; a pdf version of the paper is also available in this this distribution: AAAWSING/papers/iGrid-NL101-v6.pdf. In fig. 3 of that paper, the token request process by the VMTC is depicted. This following files that you can find in: AAAWSING/AAA/PolicyMng/igrid_files



are involved in this process: AAAVMT.xml The AAA request for obtaining a token AAARequestVMT.xsd The schema to validate the AAA request AAAVMT.policy The policy the AAA toolkit uses to come to an AuthZ AAAReplyVMT.xsd The schema that the AAA toolkit uses to construct a reply to the

VMTC The ASMs are not present in this distribution, because the AAA toolkit in this distribution would not be able to make call-outs to DRAC. In fig. 4, the usage of a token is depicted, and the following files are involved: AAAVMTPeP.xml The AAA request for provisioning path by means of a token AAARequestVMT.xsd The schema to validate the AAA request AAAVMTPeP.policy The policy the AAA toolkit uses to come to an AuthZ AAAReplyVMT.xsd The schema that the AAA toolkit uses to construct a reply to the

VMTC Also in this distribution (AAAWSING/papers/IEEE_COMMAG-44-3.pdf), is a paper [5] describing the provisioning framework itself more elaborately and covering a policy example.



5.3 Policy Language Syntax The policy syntax is defined as follows: DrivingPolicy ::= "if" "(" Condition ")" "then" "(" ActionList ")" "else" "(" ActionList ")" Condition ::= Bool | Var | {Var "="}? Procedure | ComputedBoolean | UnaryBooleanOperator Condition | "(" Condition BinaryBooleanOperator Condition ")" UnaryBooleanOperator ::= "!" BinaryBooleanOperator ::= "&&" | "||" Procedure ::= ProcedureName "(" ARGList ")" ARGList ::= {ARG {"," ARG}*}? ARG ::= Bool | String | ComputedBoolean | NonBooleanExpr ComputedBoolean ::= "(" NonBooleanExp ComparisonOperator NonBooleanExpr ")" ComparisonOperator ::= "==" | ">" | ">=" | "<" | "<=" | "!=" NonBooleanExpr ::= Int | Float | Var | Procedure | UnaryArithmeticOperator NonBooleanExpr | "(" NonBooleanExpr BinaryArithmeticOperator NonBooleanExpr ")" UnaryArithmeticOperator ::= "-" BinaryArithmeticOperator ::= "+" | "-" | "/" | "*" | "%" | "&" | "|" ActionList ::= {Action {";" Action}*}? Action ::= Var "=" Bool | Var "=" String | Var "=" ComputedBoolean | Var "=" NonBooleanExpr | Procedure | DrivingPolicy Var ::= Source {"." Source}* Source ::= Identifier ProcedureName ::= Identifier "::" Identifier "." Identifier Identifier ::= "[a-zA-Z_].[a-zA-Z0-9_]*"



String ::= "\"[^"\n]*\"" Int ::= "-?[0-9]+" Float ::= "-?[0-9]+\.[0-9]*(E-?[0-9]+)?" Bool ::= "(true|false)" Policies are loaded into the RBE by connecting to the policies database and matching the type of the AAARequest against the name of the policy in the database, e.g., AAAM8B. The AAAPolicy class can be found in the directory AAAWSING/AAA/policy (the classes are not in the build path, but they are included as JARs where needed). The policy class contain three stacks storing the conditions, then-action list and the else-action list. In the next section an example policy from the M8B demo is discussed.

5.4 Defining a Policy, Constructing a Reply and Calling an ASM As an illustration of a policy, we take the policy to access the M8B service in the agent model: if (( ( Request::AAA.Authentication.simple.username == "kip" ) && ( Request::AAA.Authentication.simple.password == "monty") )) then ( Reply::AAA.Message = "permit" ; answer = ASMsb::M8BCallerBean.callM8BService(Request::M8.Question) ; Reply::M8B.m8bresponse = answer ) else ( Reply::M8B.m8bresponse = "authentication data not valid"; Reply::AAA.Message = "deny" )

The if statement contains the condition for the AuthZ and represents AuthN. In real-world scenarios this would most likely be a call-out from an AuthN ASM to an AuthN service such as RADIUS or KERBEROS and would look like this:

if ( ASMsb::RadiusBean.AuthN(

Request::AAA.Authentication.simple.method, Request::AAA.Authentication.simple.username, Request::AAA.Authentication.simple.password, Request::AAA.Authentication.simple.realm )

) then ( ...

However, for reasons of simplicity (services like RADIUS and KERBEROS are often difficult to install), we have chosen to use the simple matching AuthN in this distribution. The condition Request::AAA.Authentication.simple.username == "kip" The RBE always looks for the Request tag (which may be seen as a namespace). The elements that follow should always match the structure of the schema, that corresponds with the AAA request. A AAA request should always contain a AAA element; in this case it may also contain a M8 element (the question to the M8B service):



<xsd:element name="AAARequest" type="AAAM8BType"/> <xsd:complexType name="AAAM8BType"> <xsd:sequence> <xsd:element name="AAA" type="AAAType"/>

<xsd:element name="M8" type="M8Type" minOccurs="0" maxOccurs="1"/> </xsd:sequence>

<xsd:attribute name="version" type="xsd:string" use="required"/> <xsd:attribute name="type" type="xsd:string" use="required"/> </xsd:complexType>

Depending on the setup, there may be additional elements specifying, e.g., additional requested resources, access specifics or credentials (like SAML assertions). Both in the condition list (the if statements) and the action list (the then statements), call-outs can be made to ASMs; in the former case to process complex credential checking, e.g., AuthN by a RADIUS service or processing SAML tokens; and in the latter case to perform actions required by the actual setup, e.g., network configuration or signing AuthZ tokens (as in the iGrid 2005 demo). However, the process of policy evaluation remains the same in every scenario. Returning to the AAAM8B policy, after the if clause, we find the then clause that will be processed if the conditions evaluate to true: then ( Reply::AAA.Message = "permit" ; answer = ASMsb::M8BCallerBean.callM8BService(Request::M8.Question) ; Reply::M8B.m8bresponse = answer )

Reply refers to the reply schema that corresponds with the policy and the submitted AAA request which is recorded in the policy database. In the M8B demo case, a AAAM8B request corresponds to the AAAM8B request schema, that, in turn, corresponds with the AAAReplyM8B reply schema (see the table in section 3). The classes derived from the schema (with the JAXB xjc compiler) are parameterized by the AAAReplyM8B class with the outcome from the policy evaluation (stored in a hash table: varTable); this class is instantiated using the name in the policy database. The AAAReplyM8B.xsd schema specifies that there should be an element AAA, and either an element M8B or Token present: <xsd:element name="AAAReply" type="AAAM8BType"/> <xsd:complexType name="AAAM8BType"> <xsd:sequence> <xsd:element name="AAA" type="AAAType"/> <xsd:sequence> <xsd:choice> <xsd:element name="M8B" type="M8BType"/> <xsd:element name="Token" type="TokenType"/> </xsd:choice> </xsd:sequence> </xsd:sequence> <xsd:attribute name="version" type="xsd:string" use="required"/> <xsd:attribute name="type" type="xsd:string" use="required"/> </xsd:complexType>

The element AAA should at least contain the element Message:



<xsd:complexType name="AAAType"> <xsd:sequence> <xsd:element name="Attribute" type="AttributeType"

minOccurs="0" maxOccurs="unbounded"/> <xsd:element name="Message" type="xsd:string" minOccurs="1" maxOccurs="1"/> </xsd:sequence> </xsd:complexType>

The Message element contains the AuthZ, i.e., permit or deny; this again depends on the outcome of the if clause in the policy: if (( ( Request::AAA.Authentication.simple.username == "kip" ) && ( Request::AAA.Authentication.simple.password == "monty") )) then ( Reply::AAA.Message = "permit" ;

.... The actual assignment to the Message variable of the AAAType class is done in the AAAReplyM8B class. In method createNodeValue a AAAType object is created (that corresponds with the element AAA in the schema) with the outcome of the policy evaluation (val): ... if (ts.startsWith("AAA.Message")) { AAAType aaa = objF.createAAAType(); aaa.setMessage(val); element = (Object) aaa; }

... Subsequently, the AAAType object is picked out of the set of all the objects created from the varTable, and assigned to the AAAReply object. ... if (elem.get(j) instanceof AAAType) { aaa = (AAAType) elem.get(j); elem.remove(j); System.out.println("add Message to AAAReply element"); }

... rpl.setAAA(aaa);

The RBE uses an ASM to call the M8B service: answer = ASMsb::M8BCallerBean.callM8BService(Request::M8.Question) ;

ASMsb indicates a call to an EJB that implements the interface to the M8B service, the M8BCallerBean. As was mentioned before, the M8BCallerBean contains the same code as the MsgClient (cf. section 3): public String callM8BService(String question) throws Exception {



String urlstr = "http://localhost:8080/M8BM/M8BallBean?wsdl"; String answer = null; System.out.println("Contacting webservice at " + urlstr); URL url = new URL(urlstr); QName qname = new QName("http://m8b2.science.uva.nl/", "M8BallService"); ServiceFactory factory = ServiceFactory.newInstance(); Service service = factory.createService(url, qname); M8Ball m8b = (M8Ball) service.getPort(M8Ball.class);

answer = m8b.askQuestion(question)); return answer; }

Note that the call in the policy corresponds to the class name and the method of the ASM. ASM code can contain any type of calculation or call-out that is desired. In this case a web service is called, but the ASM could very well contain a call-out to a network device (sending it TL1 commands), create an X.509 certificate, calculate a schedule for resource usage, etc. The answer of the M8B service is subsequently assigned to the M8B.m8bresponse variable: Reply::M8B.m8bresponse = answer

In the same way as with the AAA.Message variable, the value of answer is assigned to the m8bresponse variable in the M8BType object (which is contained in the AAAReply object). Finally, the AAAReplyM8B class marshals the AAAReply object into a DOM document and returns it to the RBE, which returns it to the AAA server, which, in turn, returns it to the client.

5.5 Building the AAA Toolkit EAR In the programmer's manual is described how to deploy all three modules in the project; this is a simple matter of copying the module files to the deploy directory of the JBoss application server. The projects have been developed with the Borland JBuilder IDE and the JBuilder project files are in the respective module directories. For the AAA toolkit we have included an ant build.xml script (we assume it is not very likely that programmers want to develop the M8B service and the M8B Web Access Controller further; so we didn't include one for those projects). In the existing structure > cd $HOME/AAAWSING/AAA/ > ant EAR does the following:

- Compile the AAAReplyM8B.xsd schema with xjc, compile the generated sources and jars them into AAAReplyM8B_msging.jar and puts it in the resrc directory

- Compile the sources in src/rbe src/aaa src/m8b



- Package the modules - Deploy AAAServer.ear

The existing code can be modified and built without modifying the configuration, but if, e.g., another ASM is added, the deployment descriptors (DDs) have to be changed to reflect this. Writing DDs by hand can be tedious and error-prone, so we recommend using an IDE like JBuilder or IntelliJ to generate these automatically.

6 WSI Features

6.1 Introduction In the original design, the AAA endpoint was implemented as a messaging endpoint using the JAXM API (see section 3). The JAXM API is now considered to be obsolete; interaction with services is now primarily placed in the realm of web services (WS) and asynchronous messaging in the realm of message providers/brokers/middleware. WSs are usually based on a remote procedure calling API (JAX-RPC or AXIS), and messaging services on message queue implementations of the JMS API. The AAA toolkit architecture is based on a request-response protocol, but it is essentially a document- or message oriented service and does not support RPC in its usual or traditional sense where service operations can be called (e.g. for rendering a picture, or starting a data-transfer); there is only one kind of procedure that can be called, viz. document evaluation procedures. This places the AAA service in the Service Oriented Architecture (SOA) paradigm (cf. [13][14][15]), and further development of the AAA toolkit focuses on adopting SOA components and WS interoperability (WSI, cf. [20]). The evolution of the WS paradigm towards a document-based operation modus can be observed from the nature of the recently adopted WS specifications, such as WS-MetadataExchange, WS-ReliableMessaging, WS-Notification, etc. These specifications (by OASIS, cf. [21], and W3C, cf. [22]) define formats and standards for messages, message exchange and message processing, and aim to facilitate and improve (web) service interoperability. Implementations of the WS interoperability stack, commonly known as WS Interoperability Techniques (WSIT), are emerging, lead by Sun (cf. [23]) and Apache (cf. [24]). Parallel to this development, the core WS reference implementations have evolved from JAX-RPC/AXIS to JAX-WS (Java API for XML-Based Web Services, cf. [27] [28]). Because the WS specifications, recommendations and other consensus-building discourse and research (such as happening in NextGRID) are often intertwined, there is no clear-cut mapping of this (commonly called) WS stack on the implementing API’s. Moreover, implementations are usually based on JSRs (Java Specification Requests), an autonomous specification development track (cf. [26]) that doesn’t necessarily follow the evolution of the WS stack. Probably the most coherent view on the WS stack implementation is from the Java EE 5.0 (cf. [31]) reference implementations, which both Apache and Sun are developing. Apache has dubbed its effort at this ‘Geronimo’ (cf. [32]), and Sun ‘Glassfish’ (cf. [33]). Geronimo is an integration and update of the Tomcat and Axis projects with additional components partially implementing the



WS stack (some of which are former Apache projects as well), while Glassfish is an integration of the Sun J2EE application server (which is superseded by Glassfish, and is now open-source) together with an update and extension of the JWSDP 1.6 API. Geronimo is not yet fully JEE 5.0 compliant, and it is interesting to see how this goal is being achieved. In Appendix B we have included a component list (the Geronimo Java EE 5.0 Report Card, cf. [30]). Under the ‘Web Application - Servlet’ specification, Tomcat appears, and under the ‘Web Services – JAX-RPC’ specification, Axis figures. From this list, it is clear that there is no clear-cut WS stack to Geronimo component mapping, and only studying the appropriate JSR specifications, WS specifications and APIs will reveal the intricacies10. It can also be observed that the Glassfish and Geronimo implementations overlap; some components are completely adopted from Glassfish (e.g., the JAXB implementation). Both Apache and Sun promote components of their application server that can often be traced back to former projects. For instance, Sun promotes a project called ‘Metro’ (cf. [39]), that has a JAX-WS subcomponent (cf. [36]). Apache promotes projects like ‘CFX’, which combines (among others) JAX-WS with Javascript, and ‘ServiceMix’, which is, indeed, a mix of SOA concepts and more conventional WS standards (WSDL) and comprises an implementation of JSR 208 (Java Business Integration, cf. [38]). Most of these emerging technologies are in a premature state, and implementing APIs often contain bugs and are poorly documented. The AAA toolkit implementation currently still uses the JWSDP 1.6 APIs, because the goal was to provide a WS compliant interface and add WSI features to it. The benefit of switching to the JAX-WS and related APIs seemed marginal in light of the status of the APIs and what we were trying to achieve. Future AAA toolkit releases are envisioned to use the upgraded APIs as they mature. The next section is an overview of implemented WSI features, a description of a resource allocation ASM that has been used in the Token-Based Networking (TBN) Supercomputing 2006 (SC06) demo and a description of the integration with another NextGRID component, viz. the Intrusion Detection System (IDS) component, developed by NEC.

6.2 The AAAXWS Module: WSDL and Message Processing The AAAXWS module is similar to the AAAWM module discussed in section 3, in the sense that is the service endpoint, it parses and validates incoming messages and handles message exchange with the RBE. This component provides a basic architecture that can readily be extended with implementations of WSI specifications. It consists of eight WSDL ports that may be individually configured for secure message exchange and requestor authentication. In this distribution, the AAAXWS module is mainly a wrapper for the original AAA request and response messaging, but the WSDL already contains some stubs that can accomodate alternative AAA request formats in future versions. Appendix G lists the WSDL for the AAA service. The AAA service has two operations: processAAARequest() and processIDSNoticification(). The latter operation is meant for interaction with an Intrusion Detection System developted by NEC, which is discussed in section

10 A very critical note on the overly complex JAX-WS API can be found on former JCP Executive committee member Richard Monsol-Haefel’s blog (cf. [34][35]). A copy-and-paste version of the blog and some other remarks can be found in this distribution as a Word document with the name: “Redeemed JAX-WS still sucks.doc”.



7, here we discuss AAA request/reply message exchange to the AAA WSDL ports and the way they are processed.

6.2.1 Setting up the AAAXWS Module and AAAXWS Client The files needed to build, deploy and run the AAAXWS module are in: $HOME/AAAWSING/AAA/ $HOME/AAAWSING/conf/ The module will build and package into the deployable file AAAServer.ear in the same way as AAAWM, described in the previous section. In the ant build script build.xml, the details of what is included in the AAAXWS module and other modules can be found, some of which is parameterized by the values found in build.properties. When building the AAAXWS module, the following configuration files are read that input to the JWSDP tools wscompile and wsdeploy. These are needed to generate the ties and the security configuration for the JAX-RPC endpoints. The configuration files and deployment descriptors can be found here: $HOME/AAAWSING/AAA/etc The configuration files constitute the basic setup of the AAAXWS module, and for building and running the scenarios described in section 6.3, they should not be changed. The security configuration for the endpoints is determined by the configuration in: $HOME/AAAWSING/conf/dynamic-server.xml At runtime, the client reads the location of the keystores and additional variables from: $HOME/AAAWSING/conf/server-security-env.properties $HOME/AAAWSING/build.properties For the server, these files should be edited to reflect your JBoss server setup and copied to the appropriate location where JBoss reads configuration files from: $HOME/jboss-4.0.3SP1/server/default/conf The AAAXWS client code is located in this directory: $HOME/AAAWSING/AAAXWSClient Its security configuration, and the key - and truststore locations are read from: $HOME/AAAWSING/conf/dynamic-client.xml $HOME/AAAWSING/conf/client-security-env.properties It can be build and run as follows: >ant build-aaa-client



>ant run-aaa-client

6.2.2 Structure of the AAAXWS Module and Message construction As was mentioned before, the wscompile and wsdeploy tools that come with JWSDP automatically generate code for the Service Endpoint Interfaces (SEIs). The jaxrpc-ri.xml, AAAService.wsdl, and web.xml are the inputs for the tools. In jaxrpc-ri.xml are eight definitions: <?xml version="1.0" encoding="UTF-8"?> <webServices xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd" version="1.0" urlPatternBase="/AAAXWS"> <endpoint name="SecureEndpoint0" displayName="AAA Service with WSS type 0" description="AAA Service with WSS type 0" port="{http://xmlsoap.org/AAA}AAAWSItype0" interface="nl.uva.science.aaa.AAAPort" implementation="nl.uva.science.aaa.AAAServerImpl" model="/WEB-INF/model.xml.gz" wsdl="/WEB-INF/AAAService.wsdl"/> ... <endpointMapping endpointName="SecureEndpoint0" urlPattern="/AAAWSItype0"/> ... <endpointMapping endpointName="SecureEndpoint7" urlPattern="/AAAWSItype7"/> </webServices> These correspond to the Port definitions in the WSDL: <service name="AAAService"> <port name="AAAWSItype0" binding="tns:AAABinding"> <soap:address location="http://localhost:8080/AAAXWS/AAAWSItype0"/> </port> ... <port name="AAAWSItype7" binding="tns:AAABinding"> <soap:address location="http://localhost:8080/AAAXWS/AAAWSItype7"/> </port> </service> </definitions> The actual AAA server, is the implementation class mentioned in the jaxrpc-ri.xml file: implementation="nl.uva.science.aaa.AAAServerImpl"



A secure SEI invocation is completely handled by callback handlers that are configured through configuration files, and the class SecurityEnvironmentHandler (SecEnvH for short). The JAX-RPC WSS configuration files are located in: $HOME/AAAWSING/conf/dynamic-client.xml $HOME/AAAWSING/conf/dynamic-server.xml For the syntax and semantics of these files, cf. Appendix C and the JWSDP tutorial(s): [50] [51]. In the next section two sample security configurations for the SEIs are discussed that explain how this works in detail and how the messages are processed. The sources of the SecEnvH and the AAA server (the AAAImpl class) can be found here: $HOME/AAAWSING/AAA/src/nl/uva/science/aaa Message construction at the client side follows a similar, but reverse procedure: first the message body is constructed, which is then passed on to the security message handlers that, in turn (if applicable), prepend a security header and invoke the SEI. The client code can be found here: $HOME/AAAWSING/AAAXWSClient/src/nl/uva/science/aaa In the class AAAClient, similar messages are constructed for all the Ports. First, the AAA request is read from file, and unmarshalled: JAXBContext jcAAARequest = JAXBContext.newInstance(aaaRequestType); Unmarshaller u = jcAAARequest.createUnmarshaller(); u.setValidating(true); Object aaaReqObj = u.unmarshal(new File(aaaRequestFile)); Marshaller m = jcAAARequest.createMarshaller(); m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE); m.setProperty(Marshaller.JAXB_SCHEMA_LOCATION,

"http://www.AAA.org/ns/AAA http://localhost/AAAM8B.xsd"); StringWriter strWriter = new StringWriter(); m.marshal(aaaReqObj, strWriter); reqStr = strWriter.toString(); strWriter.flush(); Then, depending on the type of configuration that is chosen (here the code is shown for Port Zero), the message is constructed and sent to the handlers (the stub): case (0): { java.lang.System.out.println("Service URL=" + serviceURL); AAAPort_AAAWSItype0_Stub stub = (AAAPort_AAAWSItype0_Stub) (aaaService.getAAAWSItype0()); stub._setProperty( javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY, serviceURL); if (reqStr != null) {



AuthNType[] authNRequests = {new AuthNType("jaas", "harry", "wombat", "UvA")}; AaaRequest aaaRequest = new AaaRequest ("id_0002", authNRequests, reqStr, reqStr, new M8BRequestType("Will the new AAA design be a success?")); String reply = stub.processAAARequest(aaaRequest); java.lang.System.out.println("AAA reply: " + reply); }

6.3 Sample messaging scenarios This section describes some of the possible WSS configurations and how inbound and outbound messages are processed. These scenarios are meant to show the consequences of some of the common configurations, alternatives to shortcomings of the XWS API and possible workarounds, and issues concerning message and requestor authentication.

6.3.1 Sign and Encrypt Message, Static and Dyamic Policy Configuration The most secure form of message exchange is by first signing the body, and then encrypting them. Messages to Port One and Two, with names:

{http://xmlsoap.org/AAA}AAAWSItype1

{http://xmlsoap.org/AAA}AAAWSItype2 are statically configured to Sign/Encrypt outgoing messages and Decrypt/Veryify Signature for incoming messages, both on the client and server side. The difference between them, is that the Port One configuration specifies that the requestors certificate has to be included in the security header, while Port Two specifies that a reference to a certificate should be included; this corresponds to keyReferenceType="Direct" vs keyReferenceType="Identifier" in the security configuration files11. If a reference method is used, the certificate must be in the truststore of the recipient (otherwise it can not be looked up). If the certificate is in the truststore, then the message is automatically authenticated. When a certificate is included in the header, the SecEnvH tries to validate the certificate by building a chain to a certificate in the truststore (a ‘root’ certificate). Messages with a “Direct” reference are handled by the SignatureVerificationKeyCallback (SigVkCb) class, while messages with a “Identifier” reference are handled by the CertificateValidationCallback (CertVCb) class. In the SecurityEnvironmentHandler (SecEnvH), the SigVkCb is parameterized by attaching the appropriate certificate (i.e., the one from the requestor found in the truststore) to the callback, While the CertVCb has to be provided with a class that implements the validation. Below is an excerpt from the SecEnvH code that parameterizes the SigVkCb; the implementation of the certificate validator can be found in the code; the name of the validator class is X509CertificateValidatorImpl. else if (callbacks[i] instanceof SignatureVerificationKeyCallback) { SignatureVerificationKeyCallback cb = (SignatureVerificationKeyCallback) callbacks[i];

11 For the syntax and semantics of the XWS policy configuration files, cf. Appendix C.

if (cb.getRequest() instanceof SignatureVerificationKeyCallback. X509SubjectKeyIdentifierBasedRequest) { // subject keyid request SignatureVerificationKeyCallback.X509SubjectKeyIdentifierBasedRequest request = (SignatureVerificationKeyCallback. X509SubjectKeyIdentifierBasedRequest) cb.getRequest(); X509Certificate cert = getCertificateFromTrustStore( request.getSubjectKeyIdentifier()); reqCert = cert; request.setX509Certificate(cert); if ((servletCtx != null) && (cert !=null)){ X500Principal requestorX500Principal = cert.getSubjectX500Principal(); System.out.println("requestorX500Principal" + requestorX500Principal); servletCtx.setAttribute("reqX500Principal", requestorX500Principal); } The configuration for Port One, as specified in the configuration file (cf. section 6.2.1) is12: <xwss:Port name="{http://xmlsoap.org/AAA}AAAWSItype1"> <xwss:SecurityConfiguration dumpMessages="true" enableDynamicPolicy="false">  <xwss:Sign includeTimestamp="false">  <xwss:X509Token certificateAlias="aaa-client2"

keyReferenceType="Direct"/> </xwss:Sign>  <xwss:Encrypt> <xwss:X509Token certificateAlias="aaa-server" keyReferenceType="Direct"/> </xwss:Encrypt>  <xwss:RequireEncryption> <xwss:X509Token certificateAlias="aaa-client" keyReferenceType="Direct"/> </xwss:RequireEncryption> <xwss:RequireSignature requireTimestamp="false"> <xwss:X509Token certificateAlias="aaa-server" /> </xwss:RequireSignature> </xwss:SecurityConfiguration> </xwss:Port>

An edited version of the client output containing the message sent through Port One can be found in Appendix D. In the header of the message a “Direct” reference to the certificate included in the header can be found in the KeyInfo element: 12 This excerpt is from the client-side configuration file; the server-side is identical except for the remarks.



<ds:KeyInfo> <wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1189260970990-1901490903"> <wsse:Reference URI="#XWSSGID-1189251469341-497419387" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- x509-token-profile-1.0#X509v3"/> </wsse:SecurityTokenReference> <ds:KeyInfo> Processing of this message roughly follows the following steps: 1) The handle() method of SecEnvH is called with a callback of type

DecryptionKeyCallback.X509CertificateBasedRequest

2) The private key of the AAA server is attached to the request, and handle() exits. 3) The handle() method is called again with a callback of type

CertificateValidationCallback

4) The class X509CertificateValidatorImpl is instantiated and attached to the request.

5) The symmetrical key in the header is decrypted with the private key of the AAA server, and the message body is decrypted with the symmetrical key by the callback handler.

6) The signature of the message is checked with the public key provided in the included certificate, and if it is correct, the message (i.e., the decrypted body) is passed to the AAA server.

7) The AAA server tries to look up the Principals of the requestor in its LDAP DIT. 8) If one of the Principals match an entry in the objectClass organizationalUnit

“ou=requestors”, and its dereferenced uid can be found in the objectClass

groupOfUniqueNames “cn=x509authn” then the request is passed to the RBE. The details of this authentication process can be found in this method of AAAImpl: public boolean checkX509authn(String reqPrinc)

9) The result of the policy evaluation by the RBE is returned in the applicable AAAReply format (cf. section 5.413) and subsequently passed to the SecEnvH.

10) The SecEnvH and the XWS callback handlers sign and encrypt the message using the aliases provided in the configuration file, and return it to the requestor14.

13 The type of the reply depends on the type of the request, as explained in that section 2. The type of the request is specified in the build.properties file that the AAA client uses to build its request with, i.e., the value of the parameter client.aaarequest.type. 14 In the requirements on messages received, an alias of the private key can be specified. However, this value is ignored by the decryption callback handler.



As can be observed from the output in Appendix D, the AAA server can not authenticate the requestor based on the Principals set by the callback handlers. This is because none of the Subject’s Principals match those of an entry in the LDAP DIT (for the contents of the DIT, cf. section 4.6). If the requestor signs the message with the aaa-client private key, then the Subject’s principals do match. Below is a fragment of the server’s output when the certificate with alias aaa-client (instead of aaa-client2) is used: ==== Received Message End ==== 19:40:42,272 INFO [STDOUT] Sep 8, 2007 7:40:42 PM com.sun.org.apache.xml.internal.security.encryption.XMLCipher decryptKey INFO: Decryption of key type http://www.w3.org/2001/04/xmlenc#tripledes-cbc OK 19:42:00,182 INFO [STDOUT] The message is here : <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AAARequest type="AAAM8B" version="0.1" xsi:schemaLocation="http://www.AAA.org/ns/AAA http://195.169.124.60/AAAM8B.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.AAA.org/ns/AAA"> <AAA> <Authentication> <simple> <method>dachthetniet</method> <username>harry</username> <password>wombat</password> <realm>uva</realm> </simple> </Authentication> </AAA> <M8> <Question>q</Question> </M8> </AAARequest> 19:42:29,841 INFO [STDOUT] Client Principals as set by SecPgUtil:CN=AAA Client, OU=SNE, O=UvA, L=Amsterdam, ST=Noord-Holland, C=NL 19:42:30,025 INFO [STDOUT] Matching X509 attribute C=NL 19:42:30,037 INFO [STDOUT] Matching X509 attribute ST=Noord-Holland 19:42:30,050 INFO [STDOUT] Matching X509 attribute L=Amsterdam 19:42:30,063 INFO [STDOUT] Matching X509 attribute O=UvA 19:42:30,076 INFO [STDOUT] Matching X509 attribute OU=SNE 19:42:30,090 INFO [STDOUT] Matching X509 attribute CN=AAA Client 19:42:30,111 INFO [STDOUT] Attribute found with ID: uid With Value: aaa-client 19:42:30,111 INFO [STDOUT] Value of the attribute: aaa-client 19:42:30,151 INFO [STDOUT] Attribute found with ID: uniqueMember 19:42:30,152 INFO [STDOUT] Value of the attribute: uid=aaa-client,ou=requestors,dc=aaa,dc=uva 19:42:30,152 INFO [STDOUT] Value of the attribute: uid=aaa-client2,ou=requestors,dc=aaa,dc=uva 19:42:30,158 INFO [STDOUT] X.500 Principal authorized to use X.509 cert! ID: uid Value: aaa-client On the client side, the result is as follows: [java] ==== Received Message End ==== [java] Sep 8, 2007 7:45:29 PM



com.sun.org.apache.xml.internal.security.encryption.XMLCipher decryptKey [java] INFO: Decryption of key type http://www.w3.org/2001/04/xmlenc#tripledes-cbc OK [java] AAA reply:

<?xml version="1.0" encoding="UTF-8"?> <AAAReply type="AAAM8B" version="0.1" xmlns="http://www.AAA.org/ns/AAAReply" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.AAA.org/ns/AAAReply http://localhost/AAAReplyM8B.xsd"> <AAA> <Message>permit</Message> </AAA> <M8B> <m8bresponse>Cannot Predict Now</m8bresponse> </M8B> </AAAReply>

If the message is sent through Port Two, a reference to the X.509 certificate is included in the security header. The difference in the configuration file is this line: <xwss:X509Token certificateAlias="aaa-client" keyReferenceType="Identifier"/> If the requestor sends a message through Port Two, the message will contain the following in the security header: <ds:KeyInfo> <wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1189252137694-1327471605"> <wsse:KeyIdentifier EncodingType="http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-soap-message-security- 1.0#Base64Binary" ValueType="http://docs.oasisopen.org/wss/2004/01/oasis- 200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier"> HjmdAG/UTlTDh34HvvdH4qR0Yco= </wsse:KeyIdentifier> </wsse:SecurityTokenReference> <ds:KeyInfo> As was discussed earlier, this type of reference is processed by the SigVkCb, which is parameterized by the SecEnvH. The trusted certificate with the KeyIdentifier (printed boldface above) is fetched from the truststore and attached to the request: X509Certificate cert = getCertificateFromTrustStore( request.getSubjectKeyIdentifier()); reqCert = cert; request.setX509Certificate(cert); However, this configuration will not work because the Subject’s Principals are not set by the callback handlers. Where the CertificateValidationCallback has as a side-effect creating a Subject that can be accessed by the AAAImpl class through the SubjectAccessor API, the SigVkCb does not have this side-effect. This is one of the many idiosyncrasies of the XWS API (both versions 2.0 EA and 3.0 FCS).



The XWS API has the possibility to generate policies at runtime, which can be useful in a variety of cases. We have used it in this distribution as a workaround for the problem of the unavailability of the requestor Subject in case an “Identifier” reference is used in the security header of the requestor’s message. By default, the configuration files specify that a dynamic policy configuration is used for both inbound as outbound messages; the static configurations (e.g., for the Port One and Two) override this default setting. The default is specified at the top of the configuration files: <xwss:Service> <xwss:SecurityConfiguration dumpMessages="true" enableDynamicPolicy="true"> </xwss:SecurityConfiguration> When a message is sent to one of the Ports that do not override the default, the handle() method of the SecEnvH is called with a DynamicPolicyCallback. Subsequently, the method handleDynamicSecurity is called, which will create and parameterize the appropriate callbacks. Below is an excerpt that generates and configures a policy when the requestor’s message is sent to Port Four. DynamicApplicationContext dynamicContext = (DynamicApplicationContext) callback.getDynamicContext(); StaticApplicationContext staticApplCtx = (StaticApplicationContext) dynamicContext.getStaticPolicyContext(); inBound = dynamicContext.inBoundMessage();

HashMap appCtx = dynamicContext.getRuntimeProperties(); // JAX-RPC SEI // runtime properties

servletCtx = (ServletContext) appCtx.get( "com.sun.xml.rpc.server.http.ServletContext"); String portID = (String) staticApplCtx.getPortIdentifier(); ...

else if ("{http://xmlsoap.org/AAA}AAAWSItype4".equals(portID) && (inBound == false)) {

java.lang.System.out.println("Port 4 identified"); WSSPolicyGenerator generator = (WSSPolicyGenerator) policy. policyGenerator(); EncryptionPolicy encPolicy = generator.newEncryptionPolicy(); handleEncryptionPolicy(encPolicy, inBound); SignaturePolicy sigPolicy = generator.newSignaturePolicy(); handleSignaturePolicy(sigPolicy, inBound); MessagePolicy mPolicy = new MessagePolicy(); mPolicy.dumpMessages(true); mPolicy.append(sigPolicy); mPolicy.append(encPolicy); callback.setSecurityPolicy(mPolicy);



}

else if ("{http://xmlsoap.org/AAA}AAAWSItype4".equals(portID) && (inBound == true)) {

java.lang.System.out.println("Port 4 identified"); reqCert = null; //Clear previous values of the requestor's ID reqPubKey = null; reqID = null; WSSPolicyGenerator generator = (WSSPolicyGenerator) policy. policyGenerator(); EncryptionPolicy decrPolicy = generator.newEncryptionPolicy(); handleDecryptionPolicy(decrPolicy, inBound); SignaturePolicy sigPolicy = generator.newSignaturePolicy(); handleSignaturePolicy(sigPolicy, inBound); MessagePolicy mPolicy = new MessagePolicy(); mPolicy.dumpMessages(true); mPolicy.append(decrPolicy); mPolicy.append(sigPolicy); callback.setSecurityPolicy(mPolicy); } One of the benefits of using a dynamic policy configuration is, that the AAA server’s context can be readily accessed and modified15, which happens here:

HashMap appCtx = dynamicContext.getRuntimeProperties(); // JAX-RPC SEI // runtime properties

servletCtx = (ServletContext) appCtx.get( "com.sun.xml.rpc.server.http.ServletContext"); The class variable servletCtx can now be accessed to store the Subject’s Principals when the SigVkCb is called in the next round. In sum, the steps following an inbound call to Port Four are: 1) The handleDynamicPolicy() method creates two policies: a decryption policy16 and a

signature verification policy. 2) In the next round, handle() is called with a DecryptionKeyCallback, that is handled in a

straightforward way.

3) In the following round handle()is called with a SignatureValidationKeyCallback, and the X 500 Principals of the requestor are stored in servletCtx, and the certificate is stored in the class variable reqCert.

4) The message body is passed to the AAA server, that retrieves the X 500 Principals of the requestor from the context:

15 In the sample/skeleton code accompanying the XWS APIs, Sun suggests using a ThreadLocal object if the requestor’s certificate is unavailable. Although this potentially provides a (low-level) way to access the context, it does not define the authentication procedure of the requestor and binding of the provided public key to the outbound message that is described here. 16 Counterintuitively, this has to be done by modifying a new EncryptionPolicy instance.



X500Principal reqX500Principal = (X500Principal) ctx.getAttribute("reqX500Principal"); and matches them against the data in the LDAP DIT, as described above.

5) If there is a match, the AAA Request is passed on to the RBE and evaluated.

6) The AAA server passes the result to the SecEnvH, which signs the message and uses the public key stored certificate in reqCert to encrypt the symmetrical key used to encrypt the body of the message with17.

As was mentioned earlier, the certificate must be in the truststore for this to work. For illustration, below the output of the client is listed when the server returns a message containing the result of a failed certificate lookup. [java] Sep 8, 2007 10:33:00 PM com.sun.xml.wss.impl.filter.DumpFilter process [java] INFO: ==== Received Message Start ==== [java] <?xml version="1.0" encoding="UTF-8"?> [java] <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xmlsoap.org/AAA" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> [java] <env:Body> [java] <env:Fault> [java] <faultcode xmlns:ans1="http://docs.oasis-open.org/wss/2004/01/oasis- 200401-wss-wssecurity-secext-1.0.xsd"> ans1:FailedAuthentication</faultcode> [java] <faultstring>javax.xml.crypto.KeySelectorException: com.sun.xml.wss.XWSSecurityException: No Matching public key for A90e/UtQdtwmpOp+GG1v3LKkBsI= subject key identifier found</faultstring> [java] </env:Fault> [java] </env:Body> [java] </env:Envelope> [java] ==== Received Message End ==== [java] Exception in thread "main" javax.xml.rpc.soap.SOAPFaultException: Message does not conform to configured policy: No Security Header found [java] at com.sun.xml.rpc.security.SecurityPluginUtil. getSOAPFaultException(SecurityPluginUtil.java:411) [java] at com.sun.xml.rpc.security.SecurityPluginUtil. _preHandlingHook(SecurityPluginUtil.java:183) [java] at nl.uva.science.aaa.AAAPort_AAAWSItype4_Stub. _preHandlingHook(AAAPort_AAAWSItype4_Stub.java:252) [java] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:103) [java] at nl.uva.science.aaa.AAAPort_AAAWSItype4_Stub. processAAARequest(AAAPort_AAAWSItype4_Stub.java:128) [java] at nl.uva.science.aaa.AAAClient.main(AAAClient.java:265)

17 This complies with the WSS (both versions 1.0 and 1.1) specification of the <xenc:EncryptedKey> element and processing rules (cf. [42][43]).



6.3.2 SAML Authentication SAML (Security Assertion Markup Language, cf [48]) is primarily used in a single sign-on sulotion in a multi-domain setting. More generally, trusted SAML authorities can provide information about clients (such as QoS usage rights) to services in any domain that trusts the SAML authority. In this scenario, we discuss the Holder-of-Key (HOK) SAML profile depicted below (cf. [49], ‘OC4J’ stands for Oracle Container for Java).

Figure 9: The Holder-of-Key (HOK) SAML profile scenario.

In the HOK use case, there is no trust relation between the service client and the service, but there is between the service and the SAML authority. This means that Assertions issued by the SAML authority are trusted and understood by the service, and that if a client can obtain an assertion from the SAML authority (by, e.g., authenticating with the SAML authority using an X.509 certificate), the service will be able to assign an identity, a role, service level rights, etc. An assertion basically consists of:

• An AttributeStatement, that contains a Subject (with Principals, such as an email address), and a SubjectConfirmation, usually the Subject’s public key.

• Attributes; these are variables and values that the service understands and uses to determine the service level provided to the client.

• A signature that proofs that the assertion was issued by the SAML authority. In the HOK use case, the client obtains an Assertion, signs the assertion and sends it to the service provider (possibly encrypted). With a HOK assertion, the service provider is able to check that the

Assertion originates from the SAML authority and that by checking the signature of the HOK assertion, using the client’s public key, able to establish that it orignates from the client, and the claims made in the Assertion are about him/her. HOK assertions are to be sent to the following ports:

{http://xmlsoap.org/AAA}AAAWSItype5

{http://xmlsoap.org/AAA}AAAWSItype6 Port Five is configured statically, Port Six dynamically: <xwss:Port name="{http://xmlsoap.org/AAA}AAAWSItype5"> <xwss:SecurityConfiguration dumpMessages="true"> <xwss:Sign includeTimestamp="false"> <xwss:SAMLAssertion type="HOK"/> <xwss:Target type="qname">env:Body</xwss:Target>  </xwss:Sign> <xwss:Timestamp /> </xwss:SecurityConfiguration> </xwss:Port>  In this distribution, there is no interaction with a (semi-) real SAML authority. The client has a private key in its keystore, with which he signs the Assertion; the matching SAML authority public key is used by the AAA server to check the signature. Appendix F contains an example of a HOK assertion sent to the server. The server processes this message in roughly these steps: 1) The signature of the SAML assertion is checked by the SecPlUtil. The <ds:KeyValue> element

should contain the key of the SAML authority, but this is not checked by the SecPlUtil. This is the pattern: <saml:Assertion> <ds:Signature> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>2Uw1oqBBFrpmb ...

2) If the request is sent to Port Five, handle() is called with a DynamicPolicyCallback with a AuthenticationTokenPolicy.SAMLAssertionBinding



If sent to Port Six, there is no SecurityPolicy set in the callback. In that case it will be set by handleDynamicSecurityPolicy() of the SecEnvH. This method also retrieves the servlet context from the DynamicContext RuntimeProperties: HashMap appCtx = dynamicContext.getRuntimeProperties(); // JAX-RPC SEI runtime properties

servletCtx = (ServletContext) appCtx.get("com.sun.xml.rpc.server.http.ServletContext");

Subsequently, it is processed in the next round, as when it would have been sent to Port Five.

3) Method validateSAMLAssertion() is called, in which the SAML authority public key is retrieved from the truststore and matched to the one found in the message.

4) If the keys match, and if the request is sent to Port Six, the Assertion is stored in the servlet context: servletCtx.setAttribute("samlAssertion", samlAssrt);

5) Subsequently, the signature of the HOK message is checked against the public key provided in the element <saml:ConfirmationMethod>, and the message is passed on to AAAImpl if it does.

6) AAAImpl fetches the SAML Assertion from the context, and if the attributes meet the proper criteria, passes the request on to the RBE.

7) The authority decision is returned to the requestor, signed by the AAA Server. In this scenario, the request will never be passed on to the RBE when the request is sent to Port Five, because in that case, the DynamicContext is not available. Also, the validation of the SAML Attributes is not implemented yet. The request is simply passed on if an Assertion is found. Because checking the validity of the signature takes place ‘under the hood’, it may be instructive to see what happens if an invalid signature or key is provided. Since the signature is generated automatically, providing a wrong key is easier than manipulating the signature. If on the client-side, in method createHOKSAMLAssertion() in SecEnvH, the line

KeyValue kv = kif.newKeyValue(samlPubKey);

is changed to

KeyValue kv = kif.newKeyValue(pubKey);

The public key of the client is inserted into the element <ds:KeyInfo> of the Assertion. The message is immediaty rejected, as can be observed from the server’s log: ==== Received Message End ==== 19:36:05,111 INFO [STDOUT] Sep 10, 2007 7:36:05 PM com.sun.xml.wss.impl.dsig.KeySelectorImpl resolveSamlAssertion SEVERE: WSS_DSIG0012: The signature in the SAML Assertion is invalid



19:36:05,136 INFO [STDOUT] Sep 10, 2007 7:36:05 PM com.sun.xml.wss.impl.filter.DumpFilter process INFO: ==== Sending Message Start ==== <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xmlsoap.org/AAA" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <env:Body> <env:Fault> <faultcode xmlns:ans1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ans1:FailedAuthentication</faultcode> <faultstring>SAML Assertion has invalid Signature</faultstring> </env:Fault> </env:Body> </env:Envelope> ==== Sending Message End ==== To illustrate, below an exerpt is listed from the server’s output when it is checking whether the key in the Assertion is the same as the public key of the SAML authority that is in the truststore. For the algorithm, see the method createHOKSAMLAssertion(). ==== Received Message End ==== 19:44:09,714 INFO [STDOUT] The policy is: SAMLAssertionBinding 19:44:09,715 INFO [STDOUT] The last child of the Signature node is: ds:KeyInfo 19:44:09,715 INFO [STDOUT] The length of the childnodes of KeyInfo is: 1 19:44:09,715 INFO [STDOUT] This should be ds:Modulus: ds:Modulus 19:44:09,715 INFO [STDOUT] Its value is: null 19:44:09,715 INFO [STDOUT] Stringname of modulus : Modulus 19:44:09,715 INFO [STDOUT] Node name of the base64 encoded key: #text 19:44:09,716 INFO [STDOUT] And finally... its value: 2Uw1oqBBFrpmbACB36CiIVw7KaVAPFp3UMZ2AYpfqiiiHxwqUHTGj+vr9Qf3E7IWTgKiL2sNLqS4 A3uui28W37KD5hVIZdJCoTXZtthqDYi1ykwhHmzFHW6fps23PQhq16mgsgft3DvOdyOlWBml/U9U 1AfHLseK5AF/PtdBx2M8TSMT2fqexgZhWn/K7jCTzvzMfkuO2d7bKOWgHC/+wD5iYjuoav9jFn15 yYBZDUk4P5Dnb9fInh75lhARyVmCB0CJOC/V44HVfMcjfivlaVyFGGbXE9N4Wy5CttUamGjw4Aa0 saXK7TPFqSnJ0nEFxoXgPB7OZZDU/xHSS8rK/w== 19:44:09,717 INFO [STDOUT] Should be KeyInfo element: KeyInfo 19:44:09,718 INFO [STDOUT] Should be KeyValue element: KeyValue 19:44:09,718 INFO [STDOUT] Should be RSAKey element: RSAKeyValue 19:44:09,718 INFO [STDOUT] Should be Modulus element: Modulus 19:44:09,718 INFO [STDOUT] Should be the value of the Modulus element: 2Uw1oqBBFrpmbACB36CiIVw7KaVAPFp3UMZ2AYpfqiiiHxwqUHTGj+vr9Qf3E7IWTgKiL2sNLqS4 A3uui28W37KD5hVIZdJCoTXZtthqDYi1ykwhHmzFHW6fps23PQhq16mgsgft3DvOdyOlWBml/U9U 1AfHLseK5AF/PtdBx2M8TSMT2fqexgZhWn/K7jCTzvzMfkuO2d7bKOWgHC/+wD5iYjuoav9jFn15 yYBZDUk4P5Dnb9fInh75lhARyVmCB0CJOC/V44HVfMcjfivlaVyFGGbXE9N4Wy5CttUamGjw4Aa0 saXK7TPFqSnJ0nEFxoXgPB7OZZDU/xHSS8rK/w== 19:44:09,718 INFO [STDOUT] Do the samlPubKey and the public key of the assertion match? true 19:44:09,718 INFO [STDOUT] X.509 19:44:09,719 INFO [STDOUT] Conditions: <saml:Conditions NotBefore="2007-09-10T07:44:08Z" NotOnOrAfter="2007-09-11T03:44:08Z" > </saml:Conditions>

6.3.3 Combined Scenario Runs



The server and client output of a complete run-through of all the scenarios can be found in $HOME/AAAWSING/AAA/var The file AAAWSING/AAAXWSClient/runAllCombinedScenariosAAARequest runs the AAAClient with variable values for the parameters services.wsitype (the Ports) and client.aaareqest.file (the AAA requests, containing either a valid username/password combination or not): ant run-aaa-client -Dservice.wsitype=0 -Dclient.aaarequest.file=AAAM8BAGENT.xml ant run-aaa-client -Dservice.wsitype=0 -Dclient.aaarequest.file=AAAM8BAGENTWRONGPASSWORD.xml ant run-aaa-client -Dservice.wsitype=1 -Dclient.aaarequest.file=AAAM8BAGENT.xml ant run-aaa-client -Dservice.wsitype=1 -Dclient.aaarequest.file=AAAM8BAGENTWRONGPASSWORD.xml ... There are also runs included that specify the client.iodef.file parameter, which result in an IODEF message being sent to the AAA server. This is discussed further in the next section. ant run-aaa-client -Dservice.wsitype=0 -Dclient.iodef.file=iodef_sample.xml ant run-aaa-client -Dservice.wsitype=1 -Dclient.iodef.file=iodef_sample.xml ...



7 Interaction with Auxiliary Components: Network Resource Scheduling and Intrusion Detection

The AAA toolkit/server has been deployed in many experimental and demonstrator scenarios. Because the basic architecture keeps the logic of the authorization decision process (the RBE-ASM distinction, as discussed in section 2) separate from the nature of the service(s) or resource(s) about which an authorization decision is requested and the conditions for that decision, deployment scenarios do not share an a priori resemblance. However, because the roots of the AAA toolkit lie in network provisioning, and most of the development work still takes place in that context, it has most often been deployed in such a scenario. For illustration, in the next section the Supercomputing demonstrator is described18, which is a variation and extension of the experimental iGrid setup described in [6]. In section 0, the integration of AAA with an Intrusion Detection System (IDS) developed by NEC is described. This work is part of a NextGRID collaboration between the UvA and NEC.

7.1 AAA Resource Scheduling and Reservation in Token Based Networks In the Supercomputing 2006 Token-Based GMPLS demonstrator, the AAA toolkit was deployed to handle requests for bandwidth reservation for a GMLPS network. The main objective was to show the feasibility of a system that can make advance reservations for a particular timeslots in the future, and hand out authorization tokens following a successful reservation. Advance reservations are usually advantageous when the process of making a reservation is time-consuming, and it is possible to schedule resource usage efficiently beforehand. The poster showing this process that was displayed along with the actual demo is depicted in Figure 10 below (there is also a clearer pdf version in AAAWSING/papers). The ASM with associated classes such as schedule entries can be found in: AAAWSING/AAA/src/siber The policy for a AAA request for a reservation is as follows: if ( ASMsb::AuthNJAASBean.authN (Request::AAA.Authentication.simple.username, Request::AAA.Authentication.simple.password) ) then ( if( (Request::Siber.SessionControl == "startSession") ) then ( ASMsb::SiberBean.startSession() ; Reply::AAA.Message = "permit" ;

18 Some of the details of some of the components in the demo setup are omitted because they are not directly relevant to the purpose of showing the AAA Server in this deployment setting. Further explanation of the demo is provided in the slide show, which can be found here: AAAWSING/papers/ papers/SC06rollingdemo.pps.



Reply::Siber.cryptokey = "SESSION STARTED" ) else ( ); if( (Request::Siber.SessionControl == "request" ) ) then ( key = ASMsb::SiberBean.reqRes(Request::Siber.ResReq, 1) ; Reply::AAA.Message = "permit" ; Reply::Siber.cryptokey = key ) else ( ); if ( (Request::Siber.SessionControl == "getSchedule") ) then ( Reply::Siber.keyschedule = ASMsb::SiberBean.getKeySchedule() ; Reply::AAA.Message = "permit" ) else ( ) ; if ( (Request::Siber.SessionControl == "endSession") ) then ( Reply::AAA.Message = "permit" ; Reply::Siber.cryptokey = "SESSION ENDED" ; ASMsb::SiberBean.endSession() ) else ( ) ) else ( Reply::Siber.cryptokey = "authentication data not valid"; Reply::AAA.Message = "deny" ) The schema for the request/reply can be found here: AAAWSING/schemas/AAASiber.xsd AAAWSING/schemas/AAAReplySiber.xsd Requests could be made through a web interface, similar to the interface used in the Magic eight-ball demo. A reservation request looks like this: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AAARequest type="AAASiber" version="0.1" xsi:schemaLocation="http://www.AAA.org/ns/AAA http://localhost/AAASiber.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.AAA.org/ns/AAA"> <AAA> <Authentication> <simple> <method>jaas</method> <username>harry</username> <password>wombat</password> <realm>uva</realm> </simple> </Authentication> </AAA> <Siber> <ResReq>0 1117613460 1163502000 1163509200 1 2 1 5.0 1</ResReq> <SessionControl>request</SessionControl>



</Siber> </AAARequest> The <ResReq> element contains the start and end time (and date) that the user requires his timeslots to be scheduled in, and the number of timeslots (which are five minutes in duration). Note that the sum of the timeslots (e.g., 5*5 = 25 minutes) may be smaller than the reservation window that is specified (e.g., 60 minutes), which allows the scheduler to distribute the requested timeslots over the interval, and possibly reserving timeslots for another user in the specified window. The policy shows that it is possible to make four requests, i.e., 1) to start a scheduling session, 2) to make a reservation, 3) to get the schedule from the scheduler, and 3) to end a scheduling session. The session controller, i.e., the servlet that controls the flow of JSP pages, makes a start – and end request, because it must keep track of the scheduler’s state to prevent the schedule from getting corrupted. If a user is authenticated, then the ASM’s request method is called from the RBE; this follows from the policy: if the authentication ASM returns true, then this line in the policy is executed: key = ASMsb::SiberBean.reqRes(Request::Siber.ResReq, 1) ; Resulting in calling SiberBean.resReq being called with the date in the <ResReq> element in the request and an integer (a redundant parameter; there are also parameters in the element <ResReq> that are redundant, the only relevant ones are the start and end time of the reservation window and the number of timeslots). If a the timeslots can be accomodated in the schedule a key is generated, and the schedule entry is pushed to the PEP and a schedule visualizer: cryptokey = keySchedule.putInSchedule(req); String pushToPEP = "" + keySchedule.getThisReq(req, cryptokey); System.out.println("Data to be pushed to PEP^^#: " + pushToPEP); try { svc.callSiberViz(pushToPEP); // Push entry to the PEP pepc.pushPEP(pushToPEP); // Push entry to the visualizer } catch (Exception e) { System.out.println("Call to pushResPEP failed"); e.printStackTrace(); } With the key, the user (or a software agent) is able to insert a token into an RSVP message, where the token is a hash of a part of the RSVP message signed with the key. At usage time, the PEP is then able to check whether the RSVP message is valed by verifying the token, and reject it if it is false.



Figure 10: The poster displayed at Supercomputing 2006 depicting the setup of the demo.



An excerpt from the controller and the AAA server while a bandwidth request is being processed is listed below. &AAAMSG=&M8BMSG=This is the AAARequest constructed from your input: 20:10:37,726 INFO [[/M8BWACM]] action today is > SIBER 20:10:37,726 INFO [STDOUT] lowBW: -1 20:10:37,726 INFO [STDOUT] Startmonth as int: 10 20:10:37,727 INFO [STDOUT] Do we have the start day? 14 20:10:37,727 INFO [STDOUT] Do we have the start hour? 12 20:10:37,727 INFO [STDOUT] Tue Nov 14 12:00:00 CET 2006 20:10:37,727 INFO [STDOUT] Tue Nov 14 14:00:00 CET 2006 20:10:37,727 INFO [STDOUT] End time in millis: 1163509200727 20:10:37,727 INFO [STDOUT] User request for scheduler: 0 1117613460 163502000 1163509200 1 2 1 5.0 0 1 20:10:37,728 INFO [[/M8BWACM]] *******************sending***********************> jaas#harry#wombat#uva#request#0 1117613460 1163502000 1163509200 1 2 1 5.0 0 1 20:10:37,728 INFO [[/M8BWACM]] sendAAARequest 20:10:37,728 INFO [[/M8BWACM]] generateReq 20:10:37,728 INFO [[/M8BWACM]] In generate Siber Request 20:10:37,730 INFO [[/M8BWACM]] before JAXB 20:10:37,731 INFO [[/M8BWACM]] JAXB classloader 20:10:37,733 INFO [STDOUT] The request (in M8AAARequest): 20:10:37,734 INFO [STDOUT] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AAARequest type="AAASiber" version="0.1" xsi:schemaLocation="http://www.AAA.org/ns/AAA http://localhost /AAASiber.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.AAA.org/ns/AAA"> <AAA> <Authentication> <simple> <method>jaas</method> <username>harry</username> <password>wombat</password> <realm>uva</realm> </simple> </Authentication> </AAA> <Siber> <ResReq>0 1117613460 1163502000 1163509200 1 2 1 5.0 1</ResReq> <SessionControl>request</SessionControl> </Siber> </AAARequest> 20:10:37,734 INFO [[/M8BWACM]] msg generated 20:10:37,734 INFO [[/M8BWACM]] url done 20:10:37,735 INFO [[/M8BWACM]] cf 20:10:37,736 INFO [[/M8BWACM]] con generated 20:10:37,737 INFO [[/M8BWACM]] MessageFactory done 20:10:37,737 INFO [[/M8BWACM]] msg created 20:10:37,738 INFO [[/M8BWACM]] body done 20:10:37,738 INFO [[/M8BWACM]] doc added 20:10:37,739 INFO [[/M8BWACM]] waiting for answer from AAA... 20:10:37,742 INFO [STDOUT] *** AAAServer(onMessage): New request at Tue, 11 Sep, 2007 at 08:10:37 PM *** ...



20:10:37,812 INFO [STDOUT] RBE(evaluateCondition) Final value=true 20:10:37,812 INFO [STDOUT] ASMsb::SiberBean.reqRes>[AAARequest: null] 20:10:37,812 INFO [STDOUT] [RBE]:invokeASM >SiberBean method >reqRes 20:10:37,816 INFO [STDOUT] found ASM >> 20:10:37,826 INFO [STDOUT] Method name to be looked up: reqRes 20:10:37,826 INFO [STDOUT] reqRes 20:10:37,828 INFO [STDOUT] mode of request: 1 20:10:37,831 INFO [STDOUT] Sent request: REQ 0 1117613460 1163502000 1163509200 1163509200 1 2 1 5.0 0 1 20:10:37,832 INFO [STDOUT] Server says: ACP REQ 0 20:10:37,832 INFO [STDOUT] Sent request: RSV 0 20:10:37,872 INFO [STDOUT] Server says: ACK RSV 0 1 1163502000 0 11635023 00 0 1163502600 0 1163502900 0 1163503200 0 LKS 1 2 20:10:37,872 INFO [STDOUT] Sent request: FRZ 0 20:10:37,911 INFO [STDOUT] Server says: ACK FRZ 0 20:10:37,917 INFO [STDOUT] The BASE64 encoded key: pU8CMMCgYHn9HhyXKyZvfxj53OAg1MJeXv2sK0Kldaq9VWZWihOW onstG11w8DPunfsFgEuFwhVr ZZspM7nn3Q== 20:10:37,920 INFO [STDOUT] Data to be pushed to PEP^^#: 1163502900#0#pU8CMMCgYHn9HhyXKyZvfxj53OAg1MJeXv 2sK0Kldaq9VWZWihOWonstG11w8DPunfsFgEuFwhVrZZspM7nn3Q==#1#2~116350200 00#0#pU8CMMCgYHn9Hhy ... 20:10:38,315 INFO [STDOUT] <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AAAReply type="AAASiber" version="0.1" xsi:schemaLocation="http://www.AAA.org/ns/AAAReply http://localh ost/AAAReplySiber.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.AAA.org/n s/AAAReply"> <AAA> <Message>permit</Message> </AAA> <Siber> <cryptokey>pU8CMMCgYHn9HhyXKyZvfxj53OAg1MJeXv2sK0Kldaq9VWZWihOWonstG11w8DPunfsFgEuFwhVrZZspM7nn3Q==</cryptokey> </Siber> </AAAReply> The schedule consists of entries for the timeslots (which are all different), with identical keys and request numbers: KeySchedule: 1163502900 Reservation start time: Tue Nov 14 12:15:00 CET 2006 reqnr: 0 key: pU8CMMCgYHn9HhyXKyZvfxj53OAg1MJeXv2sK0Kldaq9VWZWihOWonstG11w8DPunfsFgEuFwhVrZZspM7nn3Q== 1163502000 Reservation start time: Tue Nov 14 12:00:00 CET 2006 reqnr: 0 key: pU8CMMCgYHn9HhyXKyZvfxj53OAg1MJeXv2sK0Kldaq9VWZWihOWonstG11w8DPunfsFgEuFwhVrZZspM7nn3Q== 1163502600 Reservation start time: Tue Nov 14 12:10:00 CET 2006



reqnr: 0 key: pU8CMMCgYHn9HhyXKyZvfxj53OAg1MJeXv2sK0Kldaq9VWZWihOWonstG11w8DPunfsFgEuFwhVrZZspM7nn3Q== 1163503200 Reservation start time: Tue Nov 14 12:20:00 CET 2006 reqnr: 0 key: pU8CMMCgYHn9HhyXKyZvfxj53OAg1MJeXv2sK0Kldaq9VWZWihOWonstG11w8DPunfsFgEuFwhVrZZspM7nn3Q== 1163502300 Reservation start time: Tue Nov 14 12:05:00 CET 2006 reqnr: 0 key: pU8CMMCgYHn9HhyXKyZvfxj53OAg1MJeXv2sK0Kldaq9VWZWihOWonstG11w8DPunfsFgEuFwhVrZZspM7nn3Q==

7.2 AAA-IDS integration Recenty NEC and the UvA have undertaken efforts to integrate the AAA toolkit and NEC’s Intrusion Detection System (IDS). These efforts have been carried out as a NextGRID experiment plan, of which the details can be found in Appendix H. The goal is to provide an integrated NextGRID security component that allows unauthorized resource and service access to be blocked at an early stage of the request process. The scenario (or AAA-IDS testbed) developed until now, largely builds on the SC06 testbed, and is depicted by Figure 11 below (for a full description of the scenario cf. Appendix I). For a description of the IDS components cf. NextGRID deliverable P4.6.5.



Figure 11: The combined AAA-IDS testbed setup.

The sensors in this diagram register failed authentication attempts or resource requests that are widely out of bounds. The scenario is under development, but the basic mechanism has been built into the AAA login module, which notifies IDS of failed authentication attempts. The code that sends alerts to IDS is in the AuthNJaas ASM and can be found in: $AAAWSING/src/authnjaar/AuthNJAASBean.java try { // attempt authentication lc.login(); } catch (LoginException le) { System.err.println("Authentication failed!"); boolean idsReportSuccess =

sendIDSAlert("http://195.169.124.61:8090/pubscribe/services/GMAProducer", "http://195.169.124.61:8090/pubscribe/services/GMAWSConsumer",

"{http://www.ccrl-nece.de/GridIDS/CorrelationService/Events}LibertyID-FF1_2"); if (!idsReportSuccess)



System.out.println("Unable to send an alert to IDS!!"); return false; } Below is an excerpt from the server output after processing a wrong username/password combination in the AAALoginModule (the contents of the message should be disregarded; it was merely used to test the AAA-IDS messaging mock-up). 13:20:52,833 INFO [STDOUT] Client Principal NEITHER set by SecPgUtil OR SecEnvH!! 13:20:52,837 INFO [STDOUT] RBE(satisfyRequest): Initialize DocumentBuilderFactory. 13:20:52,838 INFO [STDOUT] RBE(satisfyRequest): DocumentBuilderFactory initialized. 13:20:52,839 INFO [STDOUT] RBE(satisfyRequest): Parse request. 13:20:52,845 INFO [STDOUT] RBE(satisfyRequest): Process request. 13:20:52,846 INFO [STDOUT] Fetch the AAAM8B policy 13:20:52,853 INFO [STDOUT] reconstructing the policy obj 13:20:52,856 INFO [STDOUT] object is alive! 13:20:52,856 INFO [STDOUT] ASMsb::AuthNJAASBean.authN>[AAARequest: null] 13:20:52,857 INFO [STDOUT] [RBE]:invokeASM >AuthNJAASBean method >authN 13:20:52,861 INFO [STDOUT] found ASM >> 13:20:52,869 INFO [STDOUT] Method name to be looked up: authN 13:20:52,869 INFO [STDOUT] authN 13:20:52,871 INFO [STDOUT] Nu in AuthN Bean 13:20:52,871 INFO [STDOUT] Configuring XML JAAS Login Coniguration MBean 13:20:52,871 INFO [STDOUT] [AAALoginModule] username in AAA request: beavis 13:20:52,871 INFO [STDOUT] [AAALoginModule] password in AAA request: 13:20:52,871 INFO [STDOUT] n 13:20:52,871 INFO [STDOUT] o 13:20:52,871 INFO [STDOUT] p 13:20:52,871 INFO [STDOUT] a 13:20:52,872 INFO [STDOUT] i 13:20:52,872 INFO [STDOUT] n 13:20:52,872 INFO [STDOUT] n 13:20:52,872 INFO [STDOUT] o 13:20:52,872 INFO [STDOUT] g 13:20:52,872 INFO [STDOUT] a 13:20:52,872 INFO [STDOUT] i 13:20:52,872 INFO [STDOUT] n 13:20:52,873 INFO [STDOUT] Authentication failed! ... 13:20:52,951 INFO [STDOUT] <wsn:Notify xmlns:wsn="http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-01.xsd"> <wsn:NotificationMessage> <wsn:Topic Dialect=

"http://docs.oasis-open.org/wsn/2004/06/TopicExpression/Simple" xmlns:even="http://www.ccrl-nece.de/GridIDS/CorrelationService/Events"> even:LibertyID-FF1_2

</wsn:Topic> <wsn:Message> <CorrelationEvent xmlns=

"http://www.ccrl-nece.de/GridDIS/CorelationService/Events"> <MessageId>AAA_alert_id</MessageId>



<SensorURL>http://195.169.124.61:8090/pubscribe/services/GMAProducer </SensorURL> <ProtocolName>liberty</ProtocolName> <Role> <Name>ip</Name> <Identity> <Identity xmlns="">roentgen</Identity> </Identity> </Role> <Role> <Name>sp</Name> <Identity> <Identity xmlns="">bankservice</Identity> </Identity> </Role> <Weight>1.2</Weight> <Detail> <Detail xmlns="">illegal password</Detail> </Detail> <TimeStamp>2007-09-12T13:20:52.922+02:00</TimeStamp> </CorrelationEvent></wsn:Message></wsn:NotificationMessage></wsn:Notify> 13:20:52,969 INFO [STDOUT] Sending request to: http://195.169.124.61:8090/pubscribe/services/GMAProducer 13:20:52,989 INFO [STDOUT] RBE(evaluateProcedure). Return type: boolean 13:20:52,990 INFO [STDOUT] process output 13:20:52,990 INFO [STDOUT] RBE(evaluateCondition) Final value=false The IDS WS-Notification service (pubscribe19) log contains the notification, and looks like this: GMAProducer:I am here 16 the inserted entry is:INSERT INTO liberty(alertId, sensorURL,ip,sp,weight, event, timestamp) VALUES ('AAA_alert_id','http://195.169.124.61:8090/pubscribe/services/GMAProducer','roentgen','bankservice',1.2,'illegal password','2007-09-12 11:57:38') IDS collects alarms from this and other sensors over time, and tries to discover a pattern in them that is linked to particular requests ID’s or userID’s. If IDS discovers a pattern, it can send a message to the AAA server reporting this, which is done in an incident reporting format known as IODEF (cf. [53]). This can be done to any AAA WSDL Port in the appropriate WSS format, calling the processIDSNotification operation. IDS does this with client code that can also be found in the AAAXWSClient code. To send an IODEF message to the AAA server, uncomment the following line in build.properties: client.iodef.file=iodef_sample.xml. Building an IODEF message is similar to building a AAA request. An excerpt from the server’s log when processing an IODEF message is listed below. 14:30:01,783 INFO [STDOUT] Now in process AAANotification 14:30:01,783 INFO [STDOUT] IODEF Document: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <IODEF-Document lang="us-en" xsi:schemaLocation="http://www.AAA.org/ns/AAA http://195.169.124.60/draft-ietf-inch-iodef-130.xsd"

19 pubscribe is now part of the Apache “Muse” project, cf. [52].



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:ietf:params:xml:ns:iodef-1.0"> <Incident purpose="reporting"> <IncidentID name="gids_aaa_value"/> <RelatedActivity> <IncidentID name="aaa_alert_id"/> </RelatedActivity> <ReportTime>2007-07-17T16:25:36.510+02:00</ReportTime> <Description>

a cross-domain attack is detected, please take actions on the attached alerts identities </Description>

<Assessment> <Impact severity="medium"/> </Assessment> <Contact role="admin" type="person"> <ContactName>IDS administrator</ContactName> </Contact> </Incident> </IODEF-Document> The implementation of barring users from making requests in an early stage will take place in the next period (M36-M42). It will consist of a hook in the AAAImpl authentication process, i.e., a lookup in the LDAP database to find out whether the requestor is on the blacklist or not.



References [1] RFC 2903, Informational, “Generic AAA Architecture” C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence, August

2000 - http://tools.ietf.org/html/rfc2903

[2] RFC 2904, Informational, "AAA Authorization Framework" J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence, August 2000 - ftp://ftp.isi.edu/in-notes/rfc2904.txt

[3] http://www.globus.org/ogsa/ [4] http://www.w3.org/TR/ws-arch/ [5] Leon Gommans, Bas van Oudenaarde, Freek Dijkstra, Cees de Laat, Tal Lavian, Inder Monga, Arie Taal, Franco

Travostino, Alfred Wan (2006). Applications Drive Secure Lightpath Creation across Heterogeneous Domains. In: IEEE Communications Magazine, Feature topic Optical Control Planes for Grid Networks: Opportunities, Challenges and the Vision, vol. 44, no. 3, pp. 100-106.

[6] Leon Gommans, Bas van Oudenaarde, Alfred Wan, Cees de Laat, Robert Meijer, Franco Travostino, Inder Monga

(2006) Token Based Networking: Experiment NL101. In Future Generation Computer Systems 22 (1025-1031) [7] http://www.science.uva.nl/research/air/projects/aaa/demokit/ [8] http://www.jboss.com [9] http://java.sun.com/blueprints/patterns/MVC-detailed.html [10] http://java.sun.com/developer/technicalArticles/WebServices/jaxb/index.html [11] http://java.sun.com/webservices/jaxm [12] http://en.wikipedia.org/wiki/Magic_8_Ball [13] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm [14] http://opengroup.org/projects/soa/doc.tpl?gdid=10632 [15] http://www-128.ibm.com/developerworks/webservices/library/ws-improvesoa/ [16] http://www.ws-i.org/Profiles/BasicProfile-1.1.html [17] http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf [18] http://xml.coverpages.org/iodef.html [19] http://www.ietf.org/rfc/rfc2828.txt [20] http://www.ws-i.org/ [21] http://www.oasis-open.org/specs/ [22] http://www.w3.org/TR/ [23] https://wsit.dev.java.net/ [24] http://incubator.apache.org/cxf/ [25] https://jax-ws.dev.java.net/



[26] http://jcp.org/en/procedures/jcp2 [27] https://jax-ws.dev.java.net/ [28] http://jcp.org/en/jsr/detail?id=224 [29] http://geronimo.apache.org/ [30] http://cwiki.apache.org/GMOxPMGT/geronimo-java-ee-50-report-card.html [31] http://jcp.org/en/jsr/detail?id=244 [32] http://geronimo.apache.org/ [33] https://glassfish.dev.java.net/ [34] http://rmh.blogs.com/weblog/2006/04/redeemed_jaxws_.html [35] http://www.monson-haefel.com/ [36] https://jax-ws.dev.java.net/ [37] http://incubator.apache.org/cxf/ [38] http://jcp.org/aboutJava/communityprocess/final/jsr208/index.html [39] https://metro.dev.java.net/ [40] http://incubator.apache.org/servicemix/home.html [41] http://incubator.apache.org/cxf/ [42] http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf [43] http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf [44] http://openldap.org [45] http://www.zytrax.com/books/ldap/ [46] Timothy Howes et al. (2003). Understanding and Deploying LDAP Directory Services (Macmillan). [47] http://www.mcs.anl.gov/~gawor/ldap [48] http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf [49] http://download-uk.oracle.com/docs/cd/B25221_04/web.1013/b15979/usecases.htm [50] http://java.sun.com/webservices/docs/1.6/tutorial/doc/index.html [51] https://wsit-docs.dev.java.net/releases/m5/index.html [52] http://ws.apache.org/muse/ [53] http://staff.science.uva.nl/~demch/projects/iodef/index.html [54] E. Rosen, et al., Multi-Protocol Label Switching Architecture. IETF RFC 3031, 2001 [55] Label Switch Router (VLSR). http://dragon.east.isi.edu/



[56] R. Braden, et al., Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. IETF RFC2205,

2005 [57] E. Rosen, et al., Generalized Multi-Protocol Label Switching Architecture. IETF RFC 3945, 2004 [58] http://www.ja-sig.org/wiki/display/UPC/JAXP+1.3+compatibilty [59] http://people.apache.org/~edwingo/jaxp-faq.html



Appendix A: Using the JAAS Authentication ASM The distribution comes standard without an authentication module installed, because creating ASMs for authentication modules depends on your preferred authentication method, and services implementing such methods are usually complicated to install. However, we have included an authentication ASM based on JAAS that uses just the standard Java 2 libraries and a simple authentication method based on a username-password-role file. Create a directory to store the password file for authentication and copy the files to that directory: >mkdir $HOME/jboss-4.0.3SP1/server/default/data/aaa/ >cp $HOME/AAAWSING/AAA/ASM/authnjaas/password.txt $HOME/jboss-4.0.3SP1/server/default/data/aaa/ Create and generate the policy that contains the call-out to the AuthNJAAS ASM. The call-out should look like this: if ( ASMsb::AuthNJAASBean.authN (Request::AAA.Authentication.simple.username,

Request::AAA.Authentication.simple.password) ) then (

Reply::AAA.Message = "permit" ; ...

If you put a condition clause before this statement testing on the <method> element, you would be able to distinguish between the 'standard' authentication method and the AuthNJAAS authentication method from the AAA request. In the AuthNJAAASBean a login context is created in the standard J2SE manner (JAAS is part of J2SE): javax.security.auth.login.LoginContext lc = null; try { lc = new javax.security.auth.login.LoginContext("AAALM", new AAACallbackHandler(username, password)); }

However, in JBoss it doesn't seem to be possible to initialize the LoginContext with a standard JAAS configuration file (there is a sample standard JAAS configuration file in the $HOME/AAAWSING/AAA directory: authnjaas.config). Instead the file $HOME/jboss-4.0.3SP1/server/default/conf/login-config.xml

has to be modified to specify the JAAS login module. Add this entry for the AAALM parameter of the LoginContext in the login-config.xml file directly below the <policy> element: <application-policy name="AAALM"> <authentication> <login-module code="authnjaas.module.AAALoginModule" flag="required"> <module-option name="pwfile">



$HOME/jboss4.0.3SP1/server/default/data/aaa/password.txt </module-option> <module-option name="debug">true</module-option> </login-module> </authentication> </application-policy> There is an example policy file in the policy management directory with the name AAAM8BJAAS.policy, and there is an example AAAM8BAGENTJAAS.xml in the messaging client directory (note that in order to let the policy have effect you should either change the name to AAAM8B.policy or change the type of the AAARequest to AAAM8BJAAS).



Appendix B: Geronimo Java EE 5.0 Report Card This table will be used to track the progress of the Apache Geronimo Java EE 5.0 implementation. The implementation will be staged over multiple milestone builds of the 2.0 release. This incremental rollout will allow users to provide early feedback on the new functions. The milestone driver levels in the table below indicate when the code for a particular function was available. It does not make any indication as to TCK status. The project won't aim to declare overall Java EE 5.0 functional compliance and official TCK certification until Geronimo 2.0 is complete.

Spec Version JSR No.

Changes from J2EE 1.4 Latest Package(s)

Milestone Build

(Initial Drop) Web Application Technologies

Servlet Servlet 2.5 JSR 154

Maintenance Update from Servlet 2.4

Tomcat-6.0-G522103 (based on 6.0.10) Jetty-6.1-SNAPSHOT

2.0-M1

Java Server Pages JSP 2.1 JSR 245

Upgrade from JSP 2.0

Jasper-6.0-G522103 (based on 6.0.10) 2.0-M1

JSP Debug JSP Debug 1.0

JSR 45

New for Java EE 5.0

Jasper-6.0-G522103 (based on 6.0.10) 2.0-M1

Java Server Faces JSF 1.2 JSR 252

New for Java EE 5.0

Myfaces-impl-1.2.0-SNAPSHOT 2.0-M3

Java Server Pages Standard Tag Library

JSTL 1.2 JSR 52

New for Java EE 5.0 Glassfish-jstl-1.2 2.0-M1

Enterprise Application Technologies

JavaBeans Activation Framework

JAF 1.1 JSR 925

Maintenance Update from JAF 1.0

Geronimo implementation 2.0-M1

JavaMail JavaMail 1.4 JSR 919

Maintenance Update from JavaMail 1.3


Java Persistence API JPA 1.0 JSR

220 New for Java EE 5.0

OpenJPA-0.9.6-incubating 2.0-M1

Java Transactions API JTA 1.1 JSR

907

Maintenance Update from JTA 1.0


Java Message JMS 1.1 JSR Same as J2EE 1.4 Activemq-4.1- 2.0-M1



Service API 914 SNAPSHOT Java EE Connector Architecture JCA 1.5 JSR

112 Same as J2EE 1.4 Geronimo implementation 2.0-M1

Java Authorization Contract for Containers

JACC 1.1 JSR 115

Maintenance Update from JACC 1.0


Common Annotations for the Java Platform

Annotations 1.0

JSR 250

New for Java EE 5.0

Geronimo implementation

2.0-M3 - Partial support 2.0-M4 - Fully supported

Enterprise JavaBeans EJB 3.0 JSR

220 Upgrade from EJB 2.1

OpenEJB 3.0 Snapshot

2.0-M2 - Partial support 2.0-M3 - Partial support 2.0-M4 - Nearly complete support

Management

Java EE Management

Java EE Mgmt 1.1

JSR 77

Maintenance Update from Mgmt 1.0


Java EE Application Deployment

App Deploy 1.2

JSR 88

Maintenance Update from App Deploy 1.1


Web Services - Axis2

Implementing Web Services WSEE 1.2 JSR

109

Maintenance Update from WSEE 1.1


2.0-M3 - Partial support

Java API for XML-Based Web Services

JAX-WS 2.0 JSR 224

New for Java EE 5.0 Axis2 implementation 2.0-M3 - Pojo

only

Java Architecture for XML Binding JAXB 2.0 JSR


Glassfish JAXB Implementation 2.0.3 2.0-M2

Java API for XML-Based RPC

JAX-RPC 1.1

JSR 101

Same as J2EE 1.4 Axis 1.4 2.0-M3

Java API for XML JAXR 1.0 JSR Same as J2EE 1.4 Scout 0.5 2.0-M2



Registries 93 Web Service Metadata for the Java platform

WS Metadata 2.0

JSR 181

New for Java EE 5.0 Axis2 implementation 2.0-M3 -

Partial support

SOAP with Attachments API SAAJ 1.3 JSR

67 Maintenance Update from SAAJ 1.2

Axis2 implementation 2.0-M4 - Partial support

Streaming API for XML STAX 1.0 JSR

173 New for Java EE 5.0 Woodstox 3.2.0 2.0-M2

Web Services - CXF

Implementing Web Services WSEE 1.2 JSR

109 Maintenance Update from WSEE 1.1



Java API for XML-Based Web Services

JAX-WS 2.0 JSR 224

New for Java EE 5.0

CXF implementation 2.0-incubator-RC-SNAPSHOT

2.0-M2 - Pojo only 2.0-M3 - Pojo and EJB

Java Architecture for XML Binding JAXB 2.0 JSR


Glassfish JAXB Implementation 2.0.3 2.0-M2

Java API for XML-Based RPC

JAX-RPC 1.1

JSR 101 Same as J2EE 1.4 Axis 1.4 2.0-M2

Java API for XML Registries JAXR 1.0 JSR

93 Same as J2EE 1.4 Scout 0.5 2.0-M2

Web Service Metadata for the Java platform

WS Metadata 2.0

JSR 181

New for Java EE 5.0

CXF implementation - 2.0-incubator-RC-SNAPSHOT


SOAP with Attachments API SAAJ 1.3 JSR

67

Maintenance Update from SAAJ 1.2

Glassfish SAAJ implementation 1.3


Streaming API for XML STAX 1.0 JSR

173 New for Java EE 5.0 Woodstox 3.2.0 2.0-M2

Misc JDK 5.0 - Corba support ?? Not part of Java

EE 5.0 Yoko-1.0-incubating-SNAPSHOT 2.0-M4



Appendix C: XWS-Security Abstract Configuration File Schema

XWS-Security Configuration File Schema

When creating a security configuration file, there is a hierarchy within which the XML elements must be listed. This section contains an abstract sketch of the schema for the data for security configuration files. The formal schema definition can be viewed at A XWS-Security Formal Schema Definition.

Figure 4-1 shows the XML schema. The tables in Semantics of Security Configuration File Elements provide more information on the elements contained within the schema. The following notations are used to describe the schema:

• | means OR • & means AND • * means zero or more of these elements allowed • + means 1 required, more allowed • ? means zero or one element allowed • (value) means that this value is the default value for the element, so specifying this

attribute is optional.

Figure 4-1 XWS-Security Abstract Configuration File Schema

<JAXRPCSecurity> +<Service/> <SecurityEnvironmentHandler/> </JAXRPCSecurity> <Service ?name=service_identifier ?id=unique_identifier ?conformance="bsp" ?useCache=("false") | "true"> ?<SecurityConfiguration/> *<Port/> ?<SecurityEnvironmentHandler/> </Service> <SecurityConfiguration ?dumpMessages=("false")|"true" ?enableDynamicPolicy=("false")|"true"> *SecurityConfigurationElements </SecurityConfiguration> *SecurityConfigurationElements = ?<Timestamp/> | ?<SAMLAssertion type="SV"/> | ?<RequireSAMLAssertion type="SV"/> | ?<UsernameToken/> |



?<RequireUsernameToken /> | ?<RequireTimestamp /> | ?<OptionalTargets /> | <Sign/> | <Encrypt/> | <RequireSignature/> | <RequireEncryption/> <Port name="port-name" ?conformance="bsp"> *<Operation ?name="op-name"> *<SecurityConfiguration/> </Operation> </Port> <SecurityEnvironmentHandler> handler-classname </SecurityEnvironmentHandler> <Operation name="operation_name" > *<SecurityConfiguration/> </Operation> <Timestamp ?id=unique_policy_identifier ?timeout=("300")/> <UsernameToken ?id=unique_policy_identifier ?name=user_name // User name and password can also be //obtained dynamically from the //SecurityEnvironment ?password=password ?useNonce=("true")|"false" ?digestPassword=("true")|"false"/> <RequireUsernameToken ?id=unique_policy_identifier ?nonceRequired=("true")|"false" ?passwordDigestRequired=("true")|"false" ?maxClockSkew=("60") ?timestampFreshnessLimit=("300") ?maxNonceAge=("900")/> <Encrypt ?id=unique_policy_identifier > ?Key-Bearing-Token ?<KeyEncryptionMethod algorithm=("http://www.w3.org/2001/04/xmlenc#rsa- oaep-mgf1p")| "http://www.w3.org/2001/04/xmlenc#kw- tripledes"| "http://www.w3.org/2001/04/xmlenc#kw- aes128" | "http://www.w3.org/2001/04/xmlenc#kw- aes256" | "http://www.w3.org/2001/04/xmlenc#rsa- 1_5" /> ?<DataEncryptionMethod algorithm=("http://www.w3.org/2001/04/



xmlenc#aes128-cbc")| "http://www.w3.org/2001/04/ xmlenc#tripledes-cbc"| "http://www.w3.org/2001/04/ xmlenc#aes256-cbc" /> *<Target/> // of type Target or EncryptionTarget </Encrypt> <EncryptionTarget ?type=("qname")|"uri"|"xpath" ?contentOnly=("true")|"false" ?enforce=("true")|"false" value=an_appropriate_ target_identifier> *<Transform/> </EncryptionTarget> <RequireEncryption ?id=unique_policy_identifier /> ?Key-Bearing-Token ?<KeyEncryptionMethod algorithm=("http://www.w3.org/2001/04/xmlenc#rsa- oaep-mgf1p") | "http://www.w3.org/2001/04/xmlenc#kw- tripledes" | "http://www.w3.org/2001/04/xmlenc#kw- aes128" | "http://www.w3.org/2001/04/xmlenc#kw- aes256" | "http://www.w3.org/2001/04/xmlenc#rsa- 1_5" /> ?<DataEncryptionMethod algorithm=("http://www.w3.org/2001/04/ xmlenc#aes128-cbc") | "http://www.w3.org/2001/04/ xmlenc#tripledes-cbc" | "http://www.w3.org/2001/04/ xmlenc#aes128-cbc" | "http://www.w3.org/2001/04/ xmlenc#aes256-cbc" /> *<Target/>//of type Target and/or EncryptionTarget </RequireEncryption> Key-Bearing-Token= <X509Token/> | <SAMLAssertion type="HOK"/> | <SymmetricKey/> <X509Token ?id=any_legal_id //Must be unique within the resulting XML ?strId=legal_id ?certificateAlias=alias_SecurityEnvironment_understands ?keyReferenceType=("Direct")|"Identifier"|"IssuerSerialN umber" ?encodingType=("http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security- 1.0#Base64Binary") ?valueType>



<SAMLAssertion ?id=unique_policy_identifier ?authorityId=URI_of_Issuing_Authority} ?strId=unique_policy_identifier ?keyIdentifier=identifier_for_Attester_Key ?keyReferenceType=("Identifier")|"Embedded" type="HOK"|"SV" </SAMLAssertion> <RequireSAMLAssertion ?id=unique_policy_identifier ?authorityId=URI_of_Issuing_Authority> ?strId=unique_policy_identifier type="SV" ?keyReferenceType=("Identifier")|"Embedded" </RequireSAMLAssertion> <SymmetricKey keyAlias= alias/keyname_of_a_shared_key /> keyReferenceType= "Direct"|"Identifier"|"IssuerSerialNumber"| "Embedded" EncodingType=(#Base64Binary | other-wss-defined-encoding-type ValueType=token-profile-specific-value-types <Sign ?id=unique_policy_identifier ?includeTimestamp=("true")|"false"> ?Key-Bearing-Token ?<CanonicalizationMethod algorithm="http://www.w3.org/2001/10/xml- exc-c14n#" | others/> ?<SignatureMethod algorithm=("http://www.w3.org/2000/09/ xmldsig#rsa-sha1") | others/> *<Target/> //of type Target or SignatureTarget </Sign> <SignatureTarget ?type=("qname")|"uri"|"xpath" ?enforce=("true")|"false" value=an_appropriate_target_identifier> ?<DigestMethod algorithm=("http://www.w3.org/2000/09/ xmldsig#sha1") | others/> *<Transform/> </SignatureTarget> <RequireSignature ?id=unique_policy_identifier ?requireTimestamp=("true")|"false"> ?Key-Bearing-Token ?<CanonicalizationMethod algorithm=("http://www.w3.org/2001/10/ xml-exc-c14n#") | others/> ?<SignatureMethod



algorithm=("http://www.w3.org/2000/09/ xmldsig#rsa-sha1") | others/> *<Target/> //of type Target and/or SignatureTarget </RequireSignature> <Transform algorithm=supported-algorithms> *<AlgorithmParameter name="name" value="value"/> </Transform> <RequireTimestamp ?id=unique_policy_id ?maxClockSkew=("60") ?timestampFreshnessLimit=("300")/> <RequireUsernameToken ?id=unique_policy_id ?nonceRequired=("true")|"false" ?passwordDigestRequired=("true")|"false" ?maxClockSkew=("60") ?timestampFreshnessLimit=("300") ?maxNonceAge=("900") > </RequireUsernameToken> <OptionalTargets> *<Target> </OptionalTargets> <Target ?type=("qname")|"uri"|"xpath" ?contentOnly=("true")|"false" ?enforce=("true")|"false"> value </Target>

Semantics of Security Configuration File Elements

This section contains a discussion regarding the semantics of security configuration file elements.

1.2.1.1.1 JAXRPCSecurity

The <JAXRPCSecurity> element is the top-level XML element for XWS-Security configuration files for applications that use JAX-RPC. The top-level XML element for stand-alone SAAJ applications is <SecurityConfiguration>. Table 4-3 provides a description of the sub-elements of <JAXRPCSecurity>.

Table 4-3 Sub-elements of JAXRPCSecurity element Sub-elements of

JAXRPCSecurity Description

Service Indicates a JAX-RPC service within the XWS-Security environment for which XWS-Security can be configured. In this release, multiple services per configuration file are supported.

SecurityEnvironmentHandler Specifies the implementation class name of the security environment handler (Required).



1.2.1.1.2 Service

The <Service> element indicates a JAX-RPC service within the XWS-Security environment for which XWS-Security can be configured.

Note: Although the XWS-Security configuration schema allows multiple <Service> elements to appear under a <JAXRPCSecurity> element, the current release does not support this feature. The configuration reader will throw an IllegalStateException if multiple services are specified.

Table 4-4 provides a description of its attributes, Table 4-5 provides a description of its sub-elements.

Table 4-4 Attributes of Service element Attributes of

Service Description

name The name of the JAX-RPC service (optional). id The id of the JAX-RPC service (optional).

conformance Type of conformance. In this release, the choice for this attribute is restricted to bsp (optional).

useCache Determines whether caching is enabled. Default is false (optional). This flag is unused in the current release and has been introduced for future enhancements.

Table 4-5 Sub-elements of Service element Sub-elements of Service Description

SecurityConfiguration Indicates that what follows is the security configuration for the service.

Port A port within a JAX-RPC service. Any (including zero) number of these elements may be specified.

SecurityEnvironmentHandler Specifies the implementation class name of the security environment handler. If specified, overrides the SecurityEnvironmentHandler specified at the parent level. (Optional)

1.2.1.1.3 Port

The <Port> element represents a port within a JAX-RPC service. Table 4-6 provides a description of its attributes, Table 4-7 provides a description of its sub-elements.

Table 4-6 Attributes of Port element Attributes of

Port Description

name Name of the port as specified in the wsdl (Required).



conformance

Type of conformance. In this release, the choice for this attribute is restricted to bsp. In this release, XWS-Security is conformant to Basic Security Profile (BSP) for messages that are created and sent. When conformance is set to bsp, messages are checked for BSP compliance before being sent. For more information on BSP, read What is Basic Security Profile (BSP)? This EA implementation of this feature will be more complete in the FCS release (optional).

Table 4-7 Sub-elements of Port element Sub-elements of Port Description

SecurityConfiguration Indicates that what follows is security configuration for the port. This over-rides any security configured for the service.

Operation Indicates a port within a JAX-RPC service. Any (including zero) number of these elements may be specified.

1.2.1.1.4 Operation

The <Operation> element creates a security configuration at the operation level, which takes precedence over port and service-level security configurations. Table 4-8 provides a description of its attributes, Table 4-9 provides a description of its sub-elements.

Table 4-8 Attributes of Operation Attributes of

Operation Description

name Name of the operation as specified in the WSDL file, for example, name="{http://xmlsoap.org/Ping}Ping0". (Required)

Table 4-9 Sub-elements of Operation Sub-elements of

Operation Description

SecurityConfiguration This element indicates that what follows is security configuration for the operation. This overrides any security configured for the port and the service.

1.2.1.1.5 SecurityConfiguration

The <SecurityConfiguration> element specifies a security configuration. Table 4-10 provides a description of its attributes, Table 4-11 provides a description of its sub-elements. The sub-elements of SecurityConfiguration can appear in any order. The order in which they appear determines the order in which they are executed, with the exception of the OptionalTargets element.

Table 4-10 Attributes of SecurityConfiguration Attributes of

SecurityConfiguration Description



dumpMessages If dumpMessages is set to true, all incoming and outgoing messages are printed at the standard output. The default value is false (Optional).

enableDynamicPolicy If enableDynamicPolicy is set to true, all incoming and outgoing messages use a dynamic security policy. The default value is false (Optional). For an example that uses this attribute, see Dynamic Policy Sample Application.

Table 4-11 Sub-elements of SecurityConfiguration Sub-elements of

SecurityConfiguration Description

Timestamp Indicates that a timestamp must be sent in the outgoing messages.

UsernameToken Indicates that a username token must be sent in the outgoing messages.

Sign Indicates that a sign operation needs to be performed on the outgoing messages.

Encrypt Indicates that an encrypt operation needs to be performed on the outgoing messages.

SAMLAssertion Indicates that a SAML assertion of subject confirmation type Sender-Vouches (SV) must be sent in the security header of the outgoing messages.

RequireTimestamp Indicates that a timestamp must be present in the incoming messages.

RequireUsernameToken Indicates that a username token must be present in the incoming messages.

RequireSignature Indicates that the incoming messages must contain a signature. RequireEncryption Indicates that the incoming messages must be encrypted.

RequireSAMLAssertion Indicates that the incoming message must contain a SAML assertion of subject confirmation type Sender-Vouches (SV).

OptionalTargets Specifies a list of elements on which security operations are not required in the incoming messages, but are allowed.

1.2.1.1.6 Timestamp

The <Timestamp> element specifies that a timestamp must be sent in outgoing messages. For a discussion of using the Timestamp element with the includeTimestamp attribute of Sign, see Using Timestamp and includeTimestamp. Table 4-12 provides a description of its attributes.

Table 4-12 Attributes of Timestamp Attributes of Timestamp Description

timeout Value in seconds after which the timestamp should be considered expired. Default value is 300.



1.2.1.1.7 UsernameToken

The <UsernameToken> element is used when a UsernameToken should be sent with outgoing messages. This UsernameToken contains the sender's user and password information. Table 4-13 provides a description of its attributes.

Table 4-13 Attributes of UsernameToken Attributes of

UsernameToken Description

name The name of the user. If not specified, security environment handler must provide it at runtime.

password The password of the user. If not specified, attempt would be made to obtain it from the security environment handler at runtime.

digestPassword Indicates whether to send password in digest form or not. Default value is true.

useNonce Indicates whether to send a nonce inside the username token or not. Sending a nonce helps in preventing replay attacks. Default value is true.

id The id to be set on the username token in the message to be sent. This is also useful in referring to the token from other places in the security configuration file.

1.2.1.1.8 Sign

The <Sign> element is used to indicate that a sign operation needs to be performed on the outgoing messages. Table 4-14 provides a description of its attributes, Table 4-15 provides a description of its sub-elements.

Table 4-14 Attributes of Sign Attributes of Sign Description

id The id to be set on the signature of the message to be sent. This is also useful in referring to the signature from other places in the security configuration file.

includeTimestamp

Indicates whether to also sign a timestamp as part of this signature or not. This is a mechanism useful in preventing replay attacks. The default value is true. Note that a true value for this attribute makes sure that a timestamp will be sent in the outgoing messages even if the <Timestamp> element has not been specified. Also note that at most one timestamp is sent in a message. When includeTimestamp is true, a Timestamp element with the default value is added and is signed (i.e., Timestamp is added as one of the targets in the corresponding signature element.)

Table 4-15 Sub-elements of Sign Sub-elements of Sign Description

X509Token Indicates the certificate corresponding to the private key used for signing. If this element is not present, attempt is made to get the default certificate



from the security environment handler. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time.

SAMLAssertion Indicates the certificate corresponding to the SAML assertion used for signing. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time.

SymmetricKey

Indicates the symmetric key corresponding to the private key used for signing. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time. (SymmetricKey signatures are not supported for signatures in this release.)

CanonicalizationMethod Indicates the canonicalization algorithm applied to the <SignedInfo> element prior to performing signature calculations.

SignatureMethod Indicates the algorithm used for signature generation and validation.

Target Specifies the target message part to be signed. Target has been deprecated and is included only for backward compatibility.

SignatureTarget Specifies the target message part to be signed.

1.2.1.1.9 Using Timestamp and includeTimestamp

The following configurations of Timestamp and the includeTimestamp attribute of the Sign element have the following effect:

1. If a <Timestamp> element is configured, a timestamp will be sent in the message. 2. If the includeTimestamp attribute on <Sign> has value true and <Timestamp> is not

configured, a timestamp (with default timeout value) will be sent in the message and included in the signature.

3. If the includeTimestamp attribute on <Sign> has value true and <Timestamp> is configured, a timestamp with the properties (e.g, timeout) specified on the <Timestamp> will be sent in the message and also be included in the signature.

4. If the includeTimestamp attribute on <Sign> has value false, a timestamp is not included in the signature.

1.2.1.1.10 Encrypt

The <Encrypt> element is used to indicate that an encrypt operation needs to be performed on the outgoing messages. Table 4-16 provides a description of its sub-elements.

Table 4-16 Sub-elements of Encrypt Sub-elements of

Encrypt Description

X509Token

Indicates the certificate to be used for encryption. If this element is not present, attempt is made to get the default certificate from the security environment handler. This element must not be specified if the <SymmetricKey> or <SAMLAssertion> sub-element of <Encrypt> is specified.

SymmetricKey Indicates the symmetric key to be used for encryption. This element must



not be specified if the <X509Token> or <SAMLAssertion> sub-element of <Encrypt> is present.

SAMLAssertion Indicates the SAML assertion to be used for encryption. This element must not be specified if the <X509Token> or <SymmetricKey> sub-element of <Encrypt> is present.

KeyEncryptionMethod Specifies the public key encryption algorithm to be used for encrypting and decrypting keys.

DataEncryptionMethod Specifies the encryption algorithm to be applied to the cipher data.

Target Identifies the resource that needs to be encrypted. The Target element has been deprecated and is provided only for backward compatibility.

EncryptionTarget Identifies the resource that needs to be encrypted.

1.2.1.1.11 SAMLAssertion

The <SAMLAssertion> element is used to define the SAML assertion to be transferred from identity providers to service providers. These assertions include statements that service providers use to make access control decisions. The SAML Sample Application provides some examples of using this element. Table 4-17 provides a description of attributes of the <SAMLAssertion> element.

Table 4-17 Attributes of SAMLAssertion Attributes of

SAMLAssertion Description

id Identifier for an assertion.

authorityId Defines the ID that may be used to acquire the identified assertion at a SAML assertion authority or responder.

strID Element content of the string identifier for the keyIdentifier.

keyIdentifier The ID for a token reference for the key identifier that references a local SAML assertion.

encodingType A parameter used to identify the security reference. When the keyIdentifier is used, this attribute is prohibited. (Prohibited)

keyReferenceType Indicates whether the token reference identifies a token by URI (Identifier) or by an embedded reference (Embedded). The default value is Identifier.

type

Indicates the type of SAML assertion to use. The choices are Holder-of-Key (HOK) and Sender-Vouches (SV). The SV confirmed assertion may not be contained in the message. The Security Token Reference (STR) identified in strID becomes a remote reference to the SV confirmed assertion. The HOK assertion contained in the message identifies the attesting entity and its signing key. Whether you choose type HOK or SV depends on where this token is located in the configuration file. A standalone <SAMLAssertion> element under <SecurityConfiguration> should be of type SV. An assertion of type HOK



can appear as a child of a <Sign> or <Encrypt> element, indicating the presence of a confirmation key that can be used for the operation. (Required)

1.2.1.1.12 RequireTimestamp

If the <RequireTimestamp> element is present, a timestamp, in the form of a wsu:Timestamp element, must be present in the incoming messages. If the RequireTimestamp element is not specified, a Timestamp is not required. A timestamp specifies the particular point in time it marks. You may also want to consider using a nonce, which is a value that you should never receive more than once. Table 4-18 provides a description of its attributes.

Table 4-18 Attributes of RequireTimestamp Attributes of

RequireTimestamp Description

id The id assigned to the timestamp.

maxClockSkew The maximum number of seconds the sending clock can deviate from the receiving clock. Default is 60.

timestampFreshnessLimit The maximum number of seconds the time stamp remains valid. Default is 300.

1.2.1.1.13 RequireUsernameToken

The <RequireUsernameToken> element is used to specify that a username token must be present in the incoming messages. Table 4-19 provides a description of its attributes.

Table 4-19 Attributes of RequireUsernameToken Attributes of

RequireUsernameToken Description

id The identifier for the UsernameToken.

passwordDigestRequired Indicates whether the username tokens in the incoming messages are required to contain the passwords in digest form or not. Default value is true. (See also: digestPassword attribute on <UsernameToken>)

nonceRequired Indicates whether a nonce is required to be present in the username tokens in the incoming messages. Default value is true. (See also: useNonce attribute on <UsernameToken>)

maxClockSkew The maximum number of seconds the sending clock can deviate from the receiving clock. Default is 60.

timestampFreshnessLimit The maximum number of seconds the time stamp remains valid. Default is 300.

maxNonceAge The maximum number of seconds the nonce is cached by the server for detecting a nonce replay. Default is 900.



1.2.1.1.14 RequireSignature

The <RequireSignature> element is specified when a digital signature is required for all specified targets. If no signature is present, an exception is thrown. In this release, the only sub-elements of RequireSignature that are verified while validating an incoming message are Target and SignatureTarget. Table 4-20 provides a description of its attributes, Table 4-21 provides a description of its sub-elements.

Table 4-20 Attributes of RequireSignature Attributes of

RequireSignature Description

id The id to be set on the signature of the message to be sent. This is also useful in referring to the signature from other places in the security configuration file.

requireTimestamp Indicates whether a timestamp must be included in the signatures in the incoming messages. Default value is true. (See also: includeTimestamp attribute on <Sign>)

Table 4-21 Sub-elements of RequireSignature Sub-elements of

RequireSignature Description

X509Token

Indicates the certificate corresponding to the private key used for signing. If this element is not present, attempt is made to get the default certificate from the security environment handler. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time.

SAMLAssertion Indicates the certificate corresponding to the SAML assertion used for signing. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time.

SymmetricKey Indicates the symmetric key corresponding to the private key used for signing. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time.

CanonicalizationMethod Indicates the canonicalization algorithm applied to the <SignedInfo> element prior to performing signature calculations.

SignatureMethod Indicates the algorithm used for signature generation and validation.

Target Specifies the target message part which was expected to be signed. Target has been deprecated and is only provided for backward compatibility.

SignatureTarget Specifies the target message part which was expected to be signed.

1.2.1.1.15 RequireEncryption

The <RequireEncryption> element is used when encryption is required for all incoming messages. If encryption is not present, an exception is thrown. In this release, the only sub-elements of RequireEncryption that are verified during validation of encrypted data in incoming



messages are Target and EncryptionTarget. Table 4-22 provides a description of its attributes, Table 4-23 provides a description of its sub-elements.

Table 4-22 Attributes of RequireEncryption Attributes of RequireEncryption Description id The id to be set on the message to be sent.

Table 4-23 Sub-elements of RequireEncryption Sub-elements of

RequireEncryption Description

X509Token

Indicates the certificate to be used for encryption. If this element is not present, attempt is made to get the default certificate from the security environment handler. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time.

SAMLAssertion Indicates the certificate corresponding to the SAML assertion used for encryption. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time.

SymmetricKey Indicates the symmetric key corresponding to the private key used for encryption. Only one of the X509Token, SAMLAssertion, and SymmetricKey elements may be present at a time.

CanonicalizationMethod Indicates the canonicalization algorithm applied to the <Encrypt> element prior to performing encrypt calculations.

DataEncryptionMethod Indicates the encryption algorithm to be applied to the cipher data.

Target Identifies the resource that was expected to be encrypted. Target has been deprecated and is only provided for backward compatibility.

EncryptionTarget Identifies the resource that was expected to be encrypted.

1.2.1.1.16 RequireSAMLAssertion

The <RequireSAMLAssertion> element is used when a Sender-Vouches (SV) SAML assertion is required for all incoming messages. If a SAML assertion is not present, an exception is thrown. Table 4-24 provides a description of its attributes.

Table 4-24 Attributes of RequireSAMLAssertion Attributes of

RequireSAMLAssertion Description

id Identifier for an assertion. (Optional) authorityId Defines an abstract identifier for the assertion-issuing authority. strID Element content of the string identifier for the keyIdentifier.

keyReferenceType Indicates whether the token reference identifies a token by AssertionId (Identifier) or by an embedded reference (Embedded). The default value is Identifier.

type Indicates to use the SV type of SAML assertion. The SV confirmed



assertion is not contained in the message. (Required)

1.2.1.1.17 OptionalTargets

The <OptionalTargets> element is used when an operation is optional for a specific target. Table 4-25 provides a description of its sub-elements.

Table 4-25 Sub-elements of OptionalTargets Sub-elements of OptionalTargets Description

Target

Indicates that a security operation is allowed to be performed on this target, but it is not required. One or more of these elements can be specified. The augmented cid:* syntax is not allowed as the value of the Target when Target is a sub-element of OptionalTargets.

1.2.1.1.18 Transform

The <Transform> element is an optional ordered list of processing steps to be applied to the resource's content before it is digested. Transforms can include operations such as canonicalization, encoding/decoding, XSLT, XPath, XML schema validation, or XInclude. The recommendation that discusses this method is the W3C XML-Signature Syntax and Processing recommendation, which can be viewed at http://www.w3.org/TR/xmldsig-core/#sec-Transforms. The following types of transform algorithms can be used: canonicalization, Base64, xpath filtering, envelope signature transform, and XSLT transform. The XWS-Security APIs Sample Application provides some examples of configuration files that use this element.

Table 4-26 provides a description of its attributes, Table 4-27 provides a description of its sub-elements.

Table 4-26 Attributes of Transform Attributes of Transform Description algorithm The algorithm to be used for signing. (Required)

Table 4-27 Sub-elements of Transform Sub-elements of Transform Description AlgorithmParameter Identifies the parameters to be supplied to the transform algorithm.

1.2.1.1.19 AlgorithmParameter

Algorithms are identified by URIs that appear as an attribute to the element that identifies the algorithms' role (DigestMethod, Transform, SignatureMethod, or CanonicalizationMethod). All algorithms used herein take parameters but in many cases the parameters are implicit. Explicit additional parameters to an algorithm appear as content elements within the algorithm role element. Such parameter elements have a descriptive element name, which is frequently algorithm specific, and MUST be in the XML Signature namespace or an algorithm specific namespace. The



XWS-Security APIs Sample Application provides some examples of configuration files that use this element.

Table 4-28 provides a description of its attributes.

Table 4-28 Attributes of AlgorithmParameter Attributes of AlgorithmParameter Description name The name of the algorithm parameter. (Required) value The value of the algorithm parameter. (Required)

1.2.1.1.20 X509Token

The <X509Token> element is used to specify the certificate to be used for encryption (for the case of encryption) or the certificate corresponding to the private key used for signing (for the case of signature). This element must not be specified if the <SymmetricKey> or <SAMLAssertion> sub-elements are present. Table 4-29 provides a description of its attributes.

Table 4-29 Attributes of X509Token Attributes of X509Token Description

id The id to be assigned to this token in the message. This attribute is useful in referring the token from other places in the security configuration file. (Optional)

strID If specified, it denotes the wsu:Id to be assigned to the Security Token Reference (STR) to be generated and inserted into the message. The inserted STR would reference the X509 token.

certificateAlias The alias associated with the token (certificate).

keyReferenceType

The reference mechanism to be used for referring to the X509 token (certificate) which was involved in the security operation, in the outgoing messages. The default value is Direct. The list of allowed values for this attribute and their description is as follows: 1. Direct - certificate is sent along with the message. 2. Identifier - subject key identifier extension value of the certificate is sent in the message. 3. IssuerSerialNumber - issuer name and serial number of the certificate are sent in the message.

encodingType The type of encoding to be used for the token. The default value is http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-

message-security-1.0#Base64Binary.

valueType The type of value to expect. The valueType can be #X509v3, #X509PKIPathv1, or #PKCS7. This release does not support #PKCS7.

1.2.1.1.21 Target



Note: In this release the Target sub-element is deprecated and is supported only for backward compatibility. The Target sub-element is being replaced with SignatureTarget and EncryptionTarget.

The <Target>target_value</Target> sub-element contains a string that can be used to identify the resource that needs to be signed or encrypted. If a Target sub-element is not specified, the default value is a target that points to the contents of the SOAP body of the message. The value of this element is specified as a text node inside this element.

You can specify attachments as targets by setting the type attribute to uri and specifying the target value as cid:<part-name>, which specifies the value of the Content-ID (CID) header of the attachment. When the Content-ID is not know until runtime, such as when auto-generated CIDs are run under JAX-RPC, the attachment can be referenced by setting the type attribute to uri and specifying the target value as attachmentRef:<part-name>, where part-name is the WSDL part name of the AttachmentPart. Auto-generated CIDs in JAX-RPC following the form <partname>=<UUID>@<Domain>. The special value cid:* can be used to refer to all attachments of a SOAPMessage.

The attributes of the <Target> element are described in Table 4-30.

Table 4-30 Attributes of Target Attributes of

Target Description

type

Indicates the type of the target value. Default value is qname. The list of allowed values for this attribute and their description is as follows: 1. qname - If the target element has a local name Name and a namespace URI some-uri, the target value is {some-uri}Name. 2. xpath - Indicates that the target value is the xpath of the target element. 3. uri - If the target element has an id some-id, then the target value is #some-id.

contentOnly Indicates whether the complete element or only the contents needs to be encrypted (or is required to be encrypted). The default value is true. (Relevant only for <Encrypt> and <RequireEncryption> targets)

enforce If true, indicates that the security operation on the target element is definitely required. Default value is true. (Relevant only for <RequireSignature> and <RequireEncryption> targets)

1.2.1.1.22 SignatureTarget

The <SignatureTarget> sub-element is called by the <SignatureMethod> element to identify the resource that needs to be signed. If neither the <SignatureTarget> nor <Target> sub-element are specified, the default value is a target that points to the contents of the SOAP body of the message. The target value is a string that specifies the object to be signed, and which is specified between the <SignatureTarget>target_value</SignatureTarget> elements. The



XWS-Security APIs Sample Application provides some examples of configuration files that use this element.


The attributes of <SignatureTarget> are described in Table 4-31, its sub-elements are described in Table 4-32.

Table 4-31 Attributes of SignatureTarget Attributes of

SignatureTarget Description

type

Indicates the type of the target value. Default value is qname. The list of allowed values for this attribute and their description is as follows: 1. qname - If the target element has a local name Name and a namespace URI some-uri, the target value is {some-uri}Name. 2. xpath - Indicates that the target value is the xpath of the target element. 3. uri - If the target element has an id some-id, then the target value is #some-id. This is the option that is used to secure message attachments.

value Indicates whether the value needs to be encrypted (or is required to be encrypted). The default value is true. (Relevant only for <Encrypt> and <RequireEncryption> targets)


Table 4-32 Sub-elements of SignatureTarget Sub-elements of SignatureTarget Description

DigestMethod Identifies the digest algorithm to be applied for signing the object.

Transform Identifies the transform algorithm to be applied before signing the object.

1.2.1.1.23 EncryptionTarget

The <EncryptionTarget> sub-element identifies the type of encrypted structure being described. If neither the <EncryptionTarget> nor <Target> sub-elements are specified, the default value is a target that points to the contents of the SOAP body of the message. The target value is a string



that specifies the object to be encrypted, and which is specified between the <EncryptionTarget>target_value</EncryptionTarget> elements.


The attributes of <EncryptionTarget> are described in Table 4-33, its sub-elements are described in Table 4-34.

Table 4-33 Attributes of EncryptionTarget Attributes of

EncryptionTarget Description

type

Indicates the type of the target value. Default value is qname. The list of allowed values for this attribute and their description is as follows: 1. qname - If the target element has a local name Name and a namespace URI some-uri, the target value is {some-uri}Name. 2. xpath - Indicates that the target value is the xpath of the target element. 3. uri - If the target element has an id some-id, then the target value is #some-id. This option is used to secure message attachments.

contentOnly Indicates whether the complete element or only the contents need to be encrypted (or is required to be encrypted). The default value is true. (Relevant only for <Encrypt> and <RequireEncryption> targets)

value Indicates whether the value needs to be encrypted (or is required to be encrypted). The default value is true. (Required)


Table 4-34 Sub-elements of EncryptionTarget Sub-elements of

EncryptionTarget Description

Transform Identifies the transform algorithm to be applied to the object to be encrypted.

1.2.1.1.24 SymmetricKey

The <SymmetricKey> element indicates the symmetric key to be used for encryption. This element must not be specified if the <X509Token> or <SAMLAssertion> sub-elements are present. Its attributes are discussed in Table 4-35.



Table 4-35 Attributes of SymmetricKey Attributes of

SymmetricKey Description

keyAlias The alias of the symmetric key to be used for encryption. This attribute is required.

1.2.1.1.25 CanonicalizationMethod

The <CanonicalizationMethod> element specifies the canonicalization algorithm to be applied to the <SignedInfo> element prior to performing signature calculations. When specified, the canonical XML [XML-C14N] standard, which is an algorithm that standardizes the way XML documents should be ordered and structured, should be applied. The recommendation that discusses this method is the W3C XML-Signature Syntax and Processing recommendation, which can be viewed at http://www.w3.org/TR/xmldsig-core/#sec-CanonicalizationMethod. Its attributes are discussed in Table 4-36.

Table 4-36 Attributes of CanonicalizationMethod Attributes of

CanonicalizationMethod Description

algorithm

The algorithm to be used for signing. There is no default value. You must explicitly add http://www.w3.org/2001/10/xml-exc-c14n#

to the transforms list in the configuration file if you want to use it. The prefix list is computed by the implementation and does not need to be specified in the configuration file. This transform will be added as the last transform regardless of its placement in the configuration file.

1.2.1.1.26 SignatureMethod

The <SignatureMethod> element specifies the algorithm used for signature generation and validation. A SignatureMethod is implicitly given two parameters: the keying info and the output of CanonicalizationMethod. The recommendation that discusses this method is the W3C XML-Signature Syntax and Processing recommendation, which can be viewed at http://www.w3.org/TR/xmldsig-core/#sec-SignatureMethod. Its attributes are discussed in Table 4-37.

Table 4-37 Attributes of SignatureMethod Attributes of SignatureMethod Description

algorithm The algorithm to be used for signing. The default value is http://www.w3.org/2000/09/xmldsig#rsa-sha1.

1.2.1.1.27 DigestMethod

The <DigestMethod> element specifies the algorithm used for generating the digest of the object to be signed. The recommendation that discusses this method is the W3C XML-Signature Syntax



and Processing recommendation, which can be viewed at http://www.w3.org/TR/xmldsig-core/#sec-DigestMethod. The attributes of <DigestMethod> are discussed in Table 4-38.

Table 4-38 Attributes of DigestMethod Attributes of

DigestMethod Description

algorithm Identifies the digest algorithm to be applied to the signed object. The default value is http://www.w3.org/2000/09/xmldsig#sha1.

1.2.1.1.28 DataEncryptionMethod

The <DataEncryptionMethod> element specifies the encryption algorithm to be applied to the cipher data. The recommendation that discusses this method is the W3C XML Encryption Syntax and Processing recommendation, which can be viewed at http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/#sec-EncryptionMethod. The attributes of <DataEncryptionMethod> are discussed in Table 4-39.

Table 4-39 Attributes of DataEncryptionMethod Attributes of

DataEncryptionMethod Description

algorithm

The algorithm to be used for encrypting data. The default value is "http://www.w3.org/2001/04/xmlenc#aes128-cbc"). Other options include: "http://www.w3.org/2001/04/xmlenc#aes256-cbc"; and "http://www.w3.org/2001/04/xmlenc#tripledes-cbc".

Note: Although the schema indicates that http://www.w3.org/2001/04/xmlenc#aes128-cbc is the default algorithm for <DataEncryptionMethod>, for backward compatibility this implementation still uses http://www.w3.org/2001/04/xmlenc#tripledes-cbc as the default.

1.2.1.1.29 KeyEncryptionMethod

The <KeyEncryptionMethod> element specifies the public key encryption algorithm to be used for encrypting and decrypting keys. Its attributes are discussed in Table 4-40.

Table 4-40 Attributes of KeyEncryptionMethod Attributes of

KeyEncryptionMethod Description

algorithm Specifies the KeyTransport/KeyWrap algorithms to be used to encrypt/decrypt a public key or secret key (key used to encrypt the data) respectively. The default value is



http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p. Other options include: "http://www.w3.org/2001/04/xmlenc#rsa-1_5"; "http://www.w3.org/2001/04/xmlenc#kw-tripledes"; "http://www.w3.org/2001/04/xmlenc#kw-aes128"; and "http://www.w3.org/2001/04/xmlenc#kw-aes256".

1.2.1.1.30 SecurityEnvironmentHandler

The <SecurityEnvironmentHandler> element specifies the implementation class name of the security environment handler. Read Writing SecurityEnvironmentHandlers for more information on SecurityEnvironmentHandlers.



Appendix D: Client output Sign/Encrypt Static Policy Configuration with Direct Certificate Key Reference C:\jdk1.5.0_08\bin\javaw -classpath "L:\projects\AAAXWS\classes;L:\projects\AAAXWS\resrc\aaaM8Bmsg.jar;L: ... " -Dservice.wm=AAAXWS -Dsaml.alias=aaa-saml -Dservice.wsitype=1 -Dendpoint.host=195.169.124.60 -Dendpoint.port=8080 -Ddefault.private.key.alias=aaa-client -Dprivate.key.alias=aaa-client -Dclient.aaarequest.type=aaaM8Bmsg -Dclient.aaarequest.file=AAAM8BAGENT.xml nl.uva.science.aaa.AAAClient <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AAARequest type="AAAM8B" version="0.1" xsi:schemaLocation="http://www.AAA.org/ns/AAA http://195.169.124.60/AAAM8B.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.AAA.org/ns/AAA"> <AAA> <Authentication> <simple> <method>dachthetniet</method> <username>harry</username> <password>wombat</password> <realm>uva</realm> </simple> </Authentication> </AAA> <M8> <Question>q</Question> </M8> </AAARequest> Service URL=http://195.169.124.60:8080/AAAXWS/AAAWSItype1 Container type: null Now reading security configuration from: ../conf/client-security-env.properties keyStoreURL:../conf\aaa-client-keystore.jks Default private key alias: aaa-client SAML alias: aaa-saml Private key alias: aaa-client Now in initKeyStore What is the URL to this KeyStore? ../conf\aaa-client-keystore.jks What type is this KeyStore? JKS Does the KeyStore contain alias aaa-saml? true Nu in initSymmKeyStore What is the URL to this KeyStore? ../conf\new-client-symmkeystore.jceks What type is this KeyStore? JCEKS Now initialized Symmetrical Keystore! 8-sep-2007 16:16:12 com.sun.xml.wss.impl.filter.DumpFilter process



INFO: ==== Sending Message Start ==== <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xmlsoap.org/AAA" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <env:Header>

<wsse:Security xmlns:wsse= "http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">

<wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- wssecurity-utility-1.0.xsd" EncodingType=

"http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0#Base64Binary"

ValueType="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-x509-token-profile-1.0#X509v3"

wsu:Id="XWSSGID-1189260969078-535401225"> MIIDZjCCAk6gAwIBAgIBADANBgkqhkiG9w0BAQUFADCBiTELMAkGA1UEBhMCTkwxF

... </wsse:BinarySecurityToken> <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <wsse:SecurityTokenReference> <wsse:Reference URI="#XWSSGID-1189260969078-535401225"

ValueType="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-x509-token-profile-1.0#X509v3"/>

</wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData>

<xenc:CipherValue>BZeYj5vBOnGalmL8lHHlbo7Iktt ...

</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#XWSSGID-11892609723121858235422"/> </xenc:ReferenceList> </xenc:EncryptedKey> <wsse:BinarySecurityToken

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-11892609690621911221215">

MIIEBDCCAuygAwIBAgIBAzANBgkqhkiG9w0BAQUFADCBiTELMA ...



</wsse:BinarySecurityToken> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces

xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse enc env ns0 xsd xsi"/> </ds:CanonicalizationMethod> <ds:SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#XWSSGID-1189260971015950584362"> <ds:DigestMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>4ckEsFq2fXzO4pn/W2zVcOfxVKg=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>Vh2AQOat9ibnZNcltLm3Sj ... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd"

wsu:Id="XWSSGID-1189260970828-858888095"> <wsse:Reference URI="#XWSSGID-11892609690621911221215"

ValueType="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-x509-token-profile-1.0#X509v3"/>

</wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </env:Header> <env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1189260971015950584362"> <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="XWSSGID-11892609723121858235422" Type="http://www.w3.org/2001/04/xmlenc#Content"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <xenc:CipherData> <xenc:CipherValue>3OSkTf2D+dV9xZUbM5lyIgoX6Ts0MGqZQchLe8i04F ... </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </env:Body> </env:Envelope>==== Sending Message End ====



8-sep-2007 16:16:14 com.sun.xml.wss.impl.filter.DumpFilter process INFO: ==== Received Message Start ==== <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:enc=http://schemas.xmlsoap.org/soap/encoding/ xmlns:ns0="http://xmlsoap.org/AAA" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<env:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">

<wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/

oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/

oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/

oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-1189251469341538711479">MIIDZjCCAk6gAwIBAgIBATANBgk

... </wsse:BinarySecurityToken> <xenc:EncryptedKey

xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <xenc:EncryptionMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <wsse:SecurityTokenReference>

<wsse:Reference URI="#XWSSGID-1189251469341538711479" ValueType="http://docs.oasis-open.org/wss/2004/01/

oasis-200401-wss-x509-token-profile-1.0#X509v3"/> </wsse:SecurityTokenReference> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>V+DHY2FFvJ6GHMDaABSeOxiY/lx4L+ ...

</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#XWSSGID-11892609710141068239992"/> </xenc:ReferenceList> </xenc:EncryptedKey> <wsse:BinarySecurityToken


EncodingType="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0#Base64Binary"

ValueType="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-x509-token-profile-1.0#X509v3"

wsu:Id="XWSSGID-1189251469341497419387">MIIDZjCCAk6gAwIBAg ...



</wsse:BinarySecurityToken>

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces

xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse enc env ns0 xsd xsi"/>

</ds:CanonicalizationMethod> <ds:SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#XWSSGID-1189260970992754750903"> <ds:DigestMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>sEO17G/KHYn3yDQw1j2xjDsMlk0=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>IeUF6dDazkXAKY2DfhhmJPNJSbS8ii

...

</ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference


wsu:Id="XWSSGID-1189260970990-1901490903"> <wsse:Reference

URI="#XWSSGID-1189251469341-497419387" ValueType="http://docs.oasis-open.org/wss/2004/01/

oasis-200401-wss-x509-token-profile-1.0#X509v3"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </env:Header>

<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/

oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1189260970992754750903">

<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="XWSSGID-11892609710141068239992" Type="http://www.w3.org/2001/04/xmlenc#Content">

<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>

<xenc:CipherData> <xenc:CipherValue>DUWSNHCr0O5tacjhs4rQRtvx5 ... </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </env:Body> </env:Envelope> ==== Received Message End ====



8-sep-2007 16:16:14 com.sun.org.apache.xml.internal.security.encryption.XMLCipher decryptKey INFO: Decryption of key type http://www.w3.org/2001/04/xmlenc#tripledes-cbc OK AAA reply: X.509 Certificate is valid, but can not be used to authorize this request.



Appendix E: LDAP Attribute Lookup To reduce the size of this document, the content of this appendix can be found can in the distribution at this location: AAAWSING/papers/Appendix_E.doc.



Appendix F: SAML HOK Assertion <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xmlsoap.org/AAA" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <env:Header>

<wsse:Security xmlns:wsse="http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">

<wsu:Timestamp xmlns:wsu="http://docs.oasis- open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility- 1.0.xsd">

<wsu:Created>2007-09-10T09:21:25Z</wsu:Created> <wsu:Expires>2007-09-10T09:26:25Z</wsu:Expires> </wsu:Timestamp> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"

xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" AssertionID="1189416084803" IssueInstant="2007-09-10T09:21:24Z" Issuer="1.2.840.113549.1.9.1=

#161373616d6c40736369656e63652e7576612e6e6c, CN=AAA SAML,OU=saml,O=AAA Attribute Authority, L=Amsterdam,ST=Noord-Holland,C=NL" MajorVersion="1" MinorVersion="1">

<saml:Conditions NotBefore= "2007-09-09T23:21:24Z" NotOnOrAfter="2007-09-10T19:21:24Z"/>

<saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier Format=

"urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="">CN=AAA Client,OU=SNE, O=UvA,L=Amsterdam, ST=Noord-Holland,C=NL</saml:NameIdentifier> <saml:SubjectConfirmation>

<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>

<ds:KeyInfo xmlns:ds= "http://www.w3.org/2000/09/xmldsig#">

<ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>xRQz0HTkHNOtw48gCMBEOp+v ... </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> </saml:SubjectConfirmation> </saml:Subject> <saml:Attribute AttributeName="cn=m8bclient,dc=M8B

Service,dc=com" AttributeNamespace="http://xmlsoap.org/AAA/AttrAuth">

<saml:AttributeValue>unlimited</saml:AttributeValue>



</saml:Attribute> </saml:AttributeStatement> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethodAlgorithm=

"http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm=

"http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#1189416084803"> <ds:Transforms> <ds:Transform Algorithm=

"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm=

"http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm=

"http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>

XszHtDFuAn3ZsLyGyRVcwqeXkFk=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>DXNNyLbP9jZeBnIBj3bQ ...

</ds:SignatureValue> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus>2Uw1oqBBFrpmbACB36CiIV ...

</ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> </ds:Signature> </saml:Assertion> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm=

"http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces xmlns=

"http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse enc env ns0 xsd xsi"/>

</ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm=

"http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI=

"#XWSSGID-1189416085600-464033828"> <ds:DigestMethod Algorithm=

"http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>3WQKCRXc7MpuEXOJMAagrthWgTE=

</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>NByY3qTX9fSBKxJ4wrzxXQyC ...

</ds:SignatureValue> <ds:KeyInfo>



<wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1189416085579-1526046267">

<wsse:KeyIdentifier ValueType= "http://docs.oasis-open.org/wss/ oasis-wss-saml-token-profile-1.0#SAMLAssertionID"> 1189416084803

</wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </env:Header>

<env:Body xmlns:wsu= "http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1189416085600-464033828">

<ns0:AAARequestContainer> <ns0:AAARequest xmlns:ans1=

"http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd" ans1:Id="id_0002">

<ns0:AuthN> <ns0:AuthNMethod>jaas</ns0:AuthNMethod> <ns0:RequestorUsername>harry</ns0:RequestorUsername> <ns0:RequestorPassword>wombat</ns0:RequestorPassword> <ns0:Realm>UvA</ns0:Realm> </ns0:AuthN> <ns0:serviceData><?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AAARequest type="AAAM8B" version="0.1"

xsi:schemaLocation="http://www.AAA.org/ns/AAA http://195.169.124.60/AAAM8B.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.AAA.org/ns/AAA">

<AAA> <Authentication> <simple> <method>dachthetniet</method> <username>harry</username> <password>wombat</password> <realm>uva</realm> </simple> </Authentication> </AAA> <M8> <Question>q</Question> </M8> </AAARequest> </ns0:serviceData> <ns0:LegacyAAARequest>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AAARequest type="AAAM8B" version="0.1" xsi:schemaLocation="http://www.AAA.org/ns/AAA http://195.169.124.60/AAAM8B.xsd"



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.AAA.org/ns/AAA">

<AAA> <Authentication> <simple> <method>dachthetniet</method> <username>harry</username> <password>wombat</password> <realm>uva</realm> </simple> </Authentication> </AAA> <M8> <Question>q</Question> </M8> </AAARequest> </ns0:LegacyAAARequest> <ns0:M8BRequest>

Will the new AAA design be a success? </ns0:M8BRequest>

</ns0:AAARequest> </ns0:AAARequestContainer> </env:Body> </env:Envelope>

Appendix G: AAA Service WSDL <?xml version='1.0' ?> <definitions xmlns:tns="http://xmlsoap.org/AAA" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0" targetNamespace="http://xmlsoap.org/AAA" name="AAA">  <types> <schema targetNamespace="http://xmlsoap.org/AAA" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <import namespace="http://docs.oasis-open.org/wss/2004/01/oasis-

200401-wss-wssecurity-utility-1.0.xsd" schemaLocation="utility.xsd"/>

<import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation="draft-ietf-inch-iodef-130.xsd"/>

<element name="AuthNMethod" type="xsd:string"/> <element name="RequestorUsername" type="xsd:string"/> <element name="RequestorPassword" type="xsd:string"/> <element name="Realm" type="xsd:string"/> <element name="AuthN" type="tns:authNType"/> <complexType name="authNType"> <xsd:sequence> <element ref="tns:AuthNMethod" minOccurs="0" maxOccurs="1"/> <element ref="tns:RequestorUsername" minOccurs="1"

maxOccurs="1"/> <element ref="tns:RequestorPassword" minOccurs="1"

maxOccurs="1"/> <element ref="tns:Realm" minOccurs="0" maxOccurs="1"/> </xsd:sequence> </complexType> <element name="M8BRequest" type="tns:m8bRequestType"/> <complexType name="m8bRequestType"> <xsd:simpleContent> <xsd:extension base="xsd:string"> </xsd:extension> </xsd:simpleContent> </complexType> <element name="serviceData" type="xsd:string"/> <element name="LegacyAAARequest" type="xsd:string"/> <element name="AAARequest" type="tns:aaaRequest"/> <complexType name="aaaRequest"> <xsd:attribute ref="wsu:Id"/> <sequence> <element ref="tns:AuthN" minOccurs="1"

maxOccurs="unbounded"/> <element ref="tns:serviceData" minOccurs="0" maxOccurs="1"/> <element ref="tns:LegacyAAARequest" minOccurs="0"

maxOccurs="1"/> <element ref="tns:M8BRequest" minOccurs="0" maxOccurs="1"/> </sequence> </complexType> <element name="IDSNotification" type="tns:idsNotification"/> <complexType name="idsNotification"> <sequence> <element ref="iodef:IODEF-Document"/> </sequence> </complexType> <element name="AAANotification" type="tns:aaaNotification"/> <complexType name="aaaNotification"> <xsd:attribute ref="wsu:Id"/> <sequence> <element ref="tns:IDSNotification" minOccurs="1"

maxOccurs="1"/> </sequence> </complexType> <element name="AAARequestContainer"

type="tns:aaaRequestContainer"/> <complexType name="aaaRequestContainer"> <sequence> <element ref="tns:AAARequest" minOccurs="1" maxOccurs="1"/> </sequence> </complexType> <element name="AAANotificationContainer"

type="tns:aaaNotificationContainer"/> <complexType name="aaaNotificationContainer"> <sequence> <element ref="tns:AAANotification" minOccurs="1"

maxOccurs="1"/> </sequence> </complexType> <element name="AuthZ" type="xsd:string" nillable="false"/> <element name="AAAReply" type="tns:aaaReply"/> <complexType name="aaaReply"> <sequence> <element ref="tns:AuthZ"/> </sequence> </complexType> </schema> </types>  <message name="AAARequest">

<part name="aaaRequestContainer" element="tns:AAARequestContainer"/>



</message> <message name="AAANotification">

<part name="aaaNotificationContainer" element="tns:AAANotificationContainer"/>

</message> <message name="AAAReply"> <part name="aaaReply" element="tns:AAAReply"/> </message> <portType name="AAAPort"> <operation name="processAAARequest"> <input message="tns:AAARequest"/> <output message="tns:AAAReply"/> </operation> <operation name="processAAANotification"> <input message="tns:AAANotification"/> <output message="tns:AAAReply"/> </operation> </portType> <binding name="AAABinding" type="tns:AAAPort">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="processAAARequest"> <soap:operation/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> <operation name="processAAANotification"> <soap:operation/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="AAAService"> <port name="AAAWSItype0" binding="tns:AAABinding"> <soap:address

location="http://localhost:8080/AAAXWS/AAAWSItype0"/> </port> <port name="AAAWSItype1" binding="tns:AAABinding"> <soap:address


location="http://localhost:8080/AAAXWS/AAAWSItype2"/>



</port> <port name="AAAWSItype3" binding="tns:AAABinding"> <soap:address





location="http://localhost:8080/AAAXWS/AAAWSItype7"/> </port> </service> </definitions>



Appendix H: NextGRID Experiment Plan

To reduce the size of this document, the content of this appendix can be found can in the distribution at this location: AAAWSING/papers/Appendix_H.doc.



Appendix I: AAA-IDS component testbed

Figure 12. A sample scenario for the interaction of intrusion prevention and detection

Basically, this scenario shows the motivation and a potential integration approach of Grid IDS developed by the T4.6 Grid intrusion detection part, and AAA developed by T4.7. In this scenario, in order to use a network belonging to a federated carrier to transfer data with Quality of Service (QoS) guarantee, a user must retrieve a token from the AAA server located at the federated carrier side first and present it to the network control modules later when establishing a data transmission tunnel. The federation protocol is controlled/monitored by Grid IDS. Any alert can be sent to Grid IDS for correlation. Possible intrusions discovered by the correlation service will be fed back to the involved partners. The detailed workflow of this scenario is as follows: 1. Federation of UserManager and ServiceManager; 2. An attacker tries to impersonate a legal user Bob to request an identity from the UserManager in order to access WS (for example, by sending the user’s name and password to the UserManager); 3. The UserManager fails to authenticate Bob, and generates an alert that is sent to GridIDS through the notification message of its sensor (for example, illegal password for Bob when trying to retrieve a federation token) ;



4. The attacker tries again and succeeds to retrieve an identity (like SAML assertion in Dynamic security scenario) from the UserManager; 5. The attacker sends a reservation request of a data/light path between Node-1 and Node-2 to a gateway service WS; 6. The WS sends the XML requests to its ServiceManager for verification; 7. The ServiceManager authenticates this incoming request as a valid one by checking the federation token attached and forwards it further to the AAA server; 8. An abnormal event in the request (for example, abnormal extra-large bandwidth request from Bob) is detected by AAA server and a corresponding alert is reported to GridIDS through its sensor as well; 9. The AAA server interacts with the scheduler for reservation; 10. The scheduler returns to the AAA the "yes" 11 and 12. The AAA server returns to the WS the Token for later use. 13. The AAA server passes the Keys 14. The WS returns the Token to the user 15. The user creates the RSVP message with Token data in the POLICY_DATA field and sends to control plane. The VLSRs check the match of Token&Key; 16. All nodes process RSVP message (forwarding/response) 17. The Ethernet switches are configured 18. LSP is set up and traffic can flow 19. GridIDS correlates two alerts and detects an intrusion related to Bob. GridIDS generates two reports to userManager and ServiceManager using their Enforcers, which can take actions (as a part of the sites’ policies, for example) such as closing Bob’s path immediately.

p4.7.3 generic authentication, authorization and ...fredwan.net/papers folder/p4.7.3.pdf ·...

Documents