DirX Access Terms Glossary and Abbreviations

The DirX Access glossary differentiates between industry-wide and DirX Access-specific terms. This chapter provides a glossary of DirX Access-specific terms and abbreviations.

Application Repository
The repository in a DirX Access Services container that stores persistent data about configuration settings, authentication policy and RBAC-based authorization information (Configuration/Policy Repository) and user account information stored in an external User Repository.

Authentication Application
A Web application that performs initial user authentication outside of PEPs and FEPs components and enables to implement complex authentication schemes.

Authentication method
A metadata object that represents an authentication method and its related data such as an assurance level. The assurance level allows administrators to define a deployment-specific ranking for authentication methods. Note that negative assurance levels are interpreted as no authentication; that is, the assurance level of an authentication method is expected to be a non-negative integer.

Authentication policy
A metadata object that associates authentication methods to resources and describes related data for this binding (such as its description or enablement status).

Authorization action
A metadata object that represents an action (such as create, read, write, update, delete) and its related data (such as its description or enablement status).

Authorization condition
A metadata object that represents a condition that needs to be satisfied (such as a date/time range, authentication method, assurance level, or IP address range) and its related data (such as its description or enablement status).

Authorization policy
A metadata object that contains authorization rules and related data (such as its description or enablement status). Note that DirX Access differentiates between business and administration authorization policies.

Authorization rule
A metadata object that associates resources, actions, and conditions with an effect (permit or deny) and related data of this binding (such as its description or enablement status). Note that DirX Access differentiates between business and administration authorization rules.

Authorization WS
A Web services application that provides XACML authorization decision-making and testing via SOAP over HTTP.

Attribute stub
Short-hand term for attribute templates with absent attribute value templates.

Attribute template
An object that comprises attribute metadata plus an attribute value template (instead attribute value). The attribute value template may be absent in an attribute template.

Attribute value template
Instructions on the construction of an attribute value (for example, search for LDAP attribute yearOfBirth in the user account identified through UUID).

Blackbox Test
The process of testing authorization decision requests against authorization policies without providing feedback about the internal PDP processing.

Client SDK
A software development kit (SDK) for creating DirX Access clients. This SDK is used in off-the-shelf DirX Access PEPs and FEPs and can also be used to create custom DirX Access clients.

Configuration/Policy Repository
A subtree in an LDAP repository where configuration and policy data used by DirX Access are placed. The Configuration/Policy Repository can be different from the User Repository.

Certificate Signing Request (CSR)
A message sent from an applicant to a certificate authority to apply for a digital identity certificate. CSR formats include the PKCS #10 specification, and the Signed Public Key and Challenge Spkac format generated by some Web browsers.

Deployment Manager
A standalone JavaEE Web application for the creation and management of base configurations in DirX Access that must be established before DirX Access can be used; for example, configurations concerning the LDAP and TCP/IP configuration of DirX Access Services and WebApplications.

Domain
A management context in DirX Access. Domains are persisted in the repository and comprise configuration and policy information or user information. DirX Access currently supports only one domain for configuration, policy and user data for each Configuration/Policy Repository and User Repository.

Federation Endpoint (FEP)
A standalone Web or Web Services (WS) application that operates as a DirX Access client and provides identity federation services. FEPs consist of:

  • SP-side FEPs, which represent the protocol endpoints for federated authentication at the Service Provider (SP) side. For example:

  • Web FEPs: SAML 1.x/2.0 FEP and OAuth 2.0 Client FEP.

  • IdP-side FEPs, which represent the protocol endpoints for federated authentication at the Identity Provider (IdP) side. For example:

  • Web FEPs: SAML 1.x/2.0 FEP and OAuth 2.0 Server FEP.

  • WS FEPs: WS-Trust STS FEP.

Federation WS
A Web services application that provides WS-Trust STS functionality via SOAP over HTTP.

Manager Web application
A JavaSE Web application that provides an HTML-based administration console via HTTP.

Native directory attribute
User-specific attributes that are interpreted by DirX Access (for example, login name, assigned roles, and external attributes provided through provisioning). Note that DirX Access also supports the processing of other attributes (for example, carLicense) which can be handled (for example, provisioned and injected as HTTP headers) but which are not interpreted by the DirX Access services.

Native service
A business service natively provided on the DirX Access Services container.

PEP
A plug-in component that operates as a DirX Access client and that provides policy enforcement functionality. PEPs consist of:

  • Protocol stack PEPs: PEPs that integrate with protocol stacks and control the execution of protocol methods. For example:

    • Web PEPs residing in HTTP stacks (Apache HTTP Server PEP, IIS PEP).

    • Web services PEPs residing in SOAP stacks (JAX-WS PEP, WCF PEP).

  • Container PEPs: PEPs that reside as plug-ins in application containers and that protect applications that execute in this container. For example:

    • JavaEE container PEPs (Tomcat PEP).

  • Application PEPs: PEPs that integrate with specific applications (for example, Web applications, WS applications, other applications) and protect this application. For example:

    • Application-source PEPs (integrating Client SDK methods with application sources, for example, through AOP or directly calling the Client SDK method in the application).

    • Application extension PEPs (Servlet-Filter PEP).

PEP authority
A symbolic identifier for a PEP that is used in the normalization of request URLs (here: the authority part of a URL). Note that this refers to Web PEPs.

Provisioning WS
A Web Services (WS) application that provides an SPML provisioning endpoint via SOAP over HTTP.

Proxy mode
A mode of DirX Access client (for example, PEP) operation in which servicing needs are satisfied through a synchronous mode of delivery. The client satisfies its servicing need by invoking methods that are served by DirX Access Servers. There are various ways to perform this servicing: direct interactions with native services, IPC via native, binary protocol or IPC via Web services.

Resource
A resource is the reference to the objects to use in authentication and authorization policies. A resource is described by a Uniform resource locator (URL).

Resource Explorer
A standalone CGI/JavaEE Web application that explores and enumerates resources of a Web or application container (supplementary to DirX Access PEPs).

Risk-based authentication (RBA)
A type of authentication in which the authentication method is determined and selected based on the risk factor of the authentication request. In risk-based authentication, the data in a user request is evaluated to estimate the risks connected with user ID recognition. It consists of two processes: general risk condition evaluation and user-context-awareness evaluation.

Role
A metadata object that associates authorization policies with subjects and related data (such as its description, role exclusion, or enablement status). Subjects may be assigned on the basis of individual users, groups and organizational units. Moreover in federated environments, subject assignment to roles can be made through attribute mappings. Note that roles always carry authorization semantics in DirX Access. They correspond to role policy sets in the RBAC profile of XACML. Note that DirX Access differentiates between business and administration roles.

Self-Signed Certificate (SS)
A certificate that is signed by the same entity whose identity it certifies. A self-signed certificate is one that is signed with its own private key.

Services Container
An application container that provides the DirX Access services to its clients (e.g., PEPs, WebApplications Container, or third-party services). It communicates directly to the underlying Application Repository.

SSO WS
A Web Services (WS) application that provides authentication and SSO functionality via SOAP over HTTP.

User Repository
A subtree in an LDAP repository where DirX Access searches for and writes user, organization unit and group objects. The User Repository can be different from the Configuration/Policy Repository.