Identity and Access Management

Dir Access V9.1
Trusted Collaboration
Identity Federation, SSO, and Access Management
for the Connected World
Everything and everyone is always
online and securing access to applications or devices provided either
as on- and off-premises services orfrom the cloud has never been more
important.
Businesses and government agencies are accelerating the formationof online partnerships to respondquickly to potential revenue opportunities, outsource non-core functions,and deliver the widest variety of services to their users.
To improve operational efficiency
and respond to user demand, they
continue to put more and more critical data and applications online for
information sharing and self-service
by consumers, mobile employees,
channel partners and suppliers.
Cloud adoption has soared as it has
proved to offer great economies ofscale for many organizations by providing a lower-cost, flexible way touse applications and services.
Meanwhile, people have come to
expect the online services they use
to be always-available, on-demand
one-stop shopping experiences
accessible through a single login andproviding them with the same lookand feel no matter what businessthey are transacting. With the recent
news of massive security breaches
of online service databases and therise in phishing, spoofing, and otherfraudulent online activities, users arealso beginning to worry that they
are giving up too much of their critical identity information to too many
Web sites.
While users may want to have a few
different identities to protect theirprivacy, creating and maintaining
a one-to-one identity relationshipwith each online service provider isa tedious chore that can lead to poor
access credentials.
Building a business-agile virtual
enterprise using on-premises applications and private and public cloudor software as service offerings
involves numerous security challenges to provide end-to-end security. The emergence of cloud, mobile
and social computing has heightened the need for strengthened
access controls to ensure compliancewith organization authentication
and authorization policies. Partners
must share or integrate their identity data, but they must do it without
overloading their IT administration
or inadvertently creating security
holes. To maximize user satisfaction,
they must provide for secure, seamless transactions between services
offered by disparate sites in different
security domains, and these transactions must be completely auditablefrom beginning to end to prove regulatory compliance. To improve theuser experience and ease the user
login burden, partners must offer
single sign-on (SSO) capabilities toapplications and services hosted
internally or in the cloud. They mustalso provide rapid onboarding of newusers to cloud services to avoid thedaunting task of manually and individually provisioning and managing
users in each software as a service(SaaS) directory.
Partners also need to consider security models for online user transactions that move collection andcontrol of identity information awayfrom online service providers andinto the hands of their users andassign the management of this data
to online identity providers.
Users of Web or cloud services often

share personal and sensitive information. This is associated with anincreasing risk of potential security
and privacy issues. Once a user has
submitted such information, he has
only limited ability to control accessto such information. To alleviate thisproblem, there is a clear need for new
approaches and methods, to allow
users to manage access to their Web
resources and data.
Next Generation Identity Federation and Access Managementwith DirX Access
These challenges are driving thedesign and deployment of new security models for access management.
Identity federation and secure Web
services are joining authentication,authorization, audit, and Web SSO as
essential capabilities for protecting
Web resources against unauthorized
use in a flexible way.
DirX Access is a comprehensive
access management, identity federation, and Web services security solution protecting resources against
unauthorized use. DirX Access:• Provides for the consistentenforcement of business security
policies through external, centralized, policy-based authentication
and authorization services.
• Enhances Web user experiencethrough local and federated single
sign-on (SSO).
• Secures eGovernment and eBusiness initiatives and provides seamless integration with business andorganizational partners throughidentity federation.
• Protects access to Web applications and devices with authentication and authorization services,
both on-premises and in the cloud.

• Supports versatile authorization
scenarios including user-managed
access.
• Decouples security management
such as authentication and authorization from application logic andensures consistent, fine-grained
entitlement management acrossmultiple applications and services.
• Enables enterprises and service
providers to deploy strong authentication solutions that reduce reliance on passwords.
• Supports regulatory compliance with audit functionality,
both within and across security
domains.

Authentication, Authorization and Audit – Core Functionality for Access Management
Authentication is the process of verifying the identity of a user requestinga service or a resource, while authorization is the process of verifyingthat an authenticated user has theright to access a requested service orresource. Authentication and authorization answer the questions “Whoare you?” and “What are you entitledto do?”
Authentication and authorization
address the real-time enforcementof enterprise security policies, while
audit automatically records thesetransactions and stores these records
securely for later compilation inreports to provide analytical insightand transparency in the identity andaccess management processes.
The processes and technologies
used to manage the users and theirlife cycles are referred to as identity
management. The set of processes
and technologies to manage, deploy,enforce, and audit access control
policies across multiple enterpriseapplications, services, and systems
is referred to as authorization or entitlement management.

Authentication
With DirX Access, authentication isprovided as an external, central service that supports a variety of wellknown authentication methods,
such as passwords, X.509 certificates, FIDO-based authentication,
Integrated Windows Authentication, smart cards, HTML forms,
one-time-pass- word (OTP) tokens,and biometrics. An internal extension interface enables to broaden
this range with additional methods, such as mobile push authen-2 | DirX Access V9.1

Authentication

Authorization

Federation
SAML, OAuth, UMA,
OpenID Connect

User Management

Entitlement
Management
XACML

SessionManagement

Secured
Systems

HTTP
REST
SOAP

Web
Single Sign -On
SSO

PolicyManagement
Fine -grained
policies

WS Security
WS -Trust,WS -Federation

Audit, Monitoring,
Logging

Delegierte, Rollen basierte
Administration

Integration und
Customization
Framework

WS -*
SAML

Web
Server
Application
ServerWeb
Services

Anwendungen

Figure 1 - DirX Access Functionality
tication. Administrators can apply
the method that best matches the
security requirements of each individual application or resource without rewriting or even touching theapplication. Decoupling authentication from the application or resource
allows the authentication service toscale easily – administrators can add
new authentication methods without affecting the applications that
depend on the service.
Centralized authentication services
also enable SSO. Users present theirlogin credentials once and are thenallowed to access all applications
and resources within the enterprisesecurity domain for which they areauthorized without having to re-authenticate/log in again.
Finally, the DirX Access central
authentication ser vice allows
authentication management to beconcentrated in one configurable
component. Because an external,
central service bypasses the need for
per-application authentication, users
no longer need to keep track of multiple login credentials, and administrators no longer need to maintainand support redundant authentication mechanisms.
A not-yet-authenticated user’s interaction with a system protected by
DirX Access leads to an initial user
authentication process. Subsequentinteractions employ the single
sign-on mechanism. Risk-based
authentication is applied in both
mentioned cases enabling to ask
the user about additional authentication when strengthening of theassurance about user’s identity isnecessary. Propagation of the successful authentication state to interconnected applications is performedby the identity federation.
Initial User Authentication
Initial authentication refers to the firsttime a user authenticates against thesystem. It is based on a user accountestablished in DirX Access and uses
standards-based initial authentication mechanisms such as:• SSL/TLS client authentication
through X.509 certificates including path validation, OCSP and CRL
support• Username/password authentication via HTTP basic or HTML form
• Second-channel OTP mechanism
enabling mobile push, SMS, ande-mail-based authentication via
HTML form• Standardized OTP algorithms IETF
RFC 4226 (HOTP) and IETF RFC
6238 (TOTP) via HTML form
• Integrated Windows Authentication (IWA) using the SPNEGO, Kerberos and NTLM authentication
protocols via HTTP
• W3C WebAuthentication basedon FIDO2 including authentication
with Microsoft Windows Hello• FIDO U2F (Universal 2nd Factor)• FIDO UAF (Universal Authentication Framework)
DirX Access enables to strengthen
the authentication process by
combining two or more authentication methods sequentially. This
represents a reasonable way ofachieving a multifactor authentication within simple deployments;for example, combining username/password with additional verification
via OTP values or username/password plus an external validation. The
combination mechanism provides
a conditional configuration of theauthentication method sequence,i.e., failure in the first method maylead either to an overall authentication failure or to invocation of a different method.
Hence, DirX Access is able to provide
more sophisticated scenarios, suchas account locking prevention – after
three unsuccessful tries with username/password the X.509 certificate

authentication is prompted, preventing from an accidental account lockand a possible costly unlocking.
DirX Access can validate the user credentials internally by performing theauthentication itself (the default), or
it can externalize the validation task
to an external validation service.
Externalizing validation is open tovarious algorithms and an interface
for third-party verifiers supports
token-type authentication credentials; for example, SAP logon tickets.
DirX Access can easily integrate existing authentication authorities andleverage the existing authentication
infrastructure.
Administrators can define the preferred authentication method to use
for each distinct resource of Web andWeb services applications or the DirX
Access-protected resources of otherapplications. In this way, administrators can easily provide the mostappropriate security level for eachindividual resource.
Administrators can use the DirX
Access Server to assign a ranking toauthentication methods. This ranking, provided by assurance levels,
indicates how secure the authentication methods are relative to eachother on a numeric scale. Assurance
levels can be used as conditions for
authorization. For example, a criticalresource can be assigned a policy
with an assurance level condition of4, requiring that users be authenticated using only the most secure
methods to achieve access. Assurance levels are defined in NIST Special Publication 800-63.
DirX Access provides step-up authentication to request a re-authentication using a stronger authentication
mechanism when accessing a morecritical resource.
Risk-based Authentication
With risk-based authentication,access to resources is secured bymeans of risk analysis. The result of
the risk analysis determines the minimum strength of the authentication
method to be used for accessing
the resource. If the user is alreadyauthenticated with an authentication method of the required strength,
access to the resource is granted;
otherwise, the use of a stronger
authentication method is enforced.
The risk analysis assesses both userand context-specific data.
The risk analysis is based on two concepts:• Evaluating predefined static conditions

securely exchanged via HTTP cookie
headers or URI rewriting.

• Considering history and/or contextual data

DirX Access manages security sessions by maintaining information on
authenticated, assured user identities. This information comprises
authentication method, authentication time, authentication credentials
and other parameters specific to thislogin event. DirX Access provides aninterface for plug-ins that fetch subject attributes from additional thirdparty sources and enrich the session
information using these attributes.

The DirX Access data collector collects and stores all parameters implying risk with the user’s account. The
collected data are further updated
after each authentication event. The
authentication process leverages
this data to run a statistical analysis
and to analyze the behavioral patterns of each authenticated user.
Risk-based authentication combines both assurance level andrisk level. Risk level is a means toestimate potential threat from anaccess request. A resource within
DirX Access is typically protected byan authentication method havingsome assurance level representing
the level of its protection. Both assurance level and risk level are used to
select an appropriate authentication
method eliminating potential risk.
To put this mechanism at work socalled risk-based conditions areused to recognize threats. Following
parameters can be configured in risk
conditions:• Resource sensitivity• IP address ranges• Time range e.g., usual working
hours of a company, 6a.m.-7p.m.,
Mo-Fri• HTTP protocol header properties,
such as type of Web browser• Custom conditions implemented
as a plugin (callout), e.g., a callout
to a third-party geolocation service which resolves a geographic
lo- cation from an IP address• Number of consecutive login failures• Login interval i.e., length of time
period between two login actions• User context to detect unusual
behavior of the authenticatinguser i.e., various data bound to theuser’s account collected by the
DirX Access RBA Data Collector for
statistical computations, for example an unusual IP ad- dress the user
tries to authenticate from.
Single Sign-On and Session Management
Once successfully authenticated,
users do not have to re-authenticate
themselves when accessing other
DirX Access-protected resources(unless a resource explicitly requires
step-up authentication) on arbitrary
servers within the same domain.
The authentication state of users is

In addition, environmental information can be handled in a configurable
way in authenticated subject representations; for example, solution
specific security environments like
information on network trust leveland device types can be provided.
DirX Access creates a new security session for each successful
initial authentication. A security
session is established between web
browsers and a DirX Access Serverusing self-contained JWT tokens
combined with referrences to theinternal distributed cache. Thisapproach achieves the best results
when it comes to performance andhigh-availability features. Dependingon the security level, the JWT tokens
can be not only digitally signed, butalso encrypted (hence, fully confidential).
An existing security session is terminated by an explicit logout (initiatedby the user), by session timeout, orby idle timeout. Thanks to the usageof the self-contained JWT session
tokens, the sessions are not terminated by a restart of the whole DirX
Access Servers cluster.
Additional DirX Access session management features include:• SSO event callout interface forthird-party plug-ins: this featureallows notifying third-party applications of SSO events such as user
logout, session timeout or idle timeout and is especially useful whenthird-party applications attach
application-specific session information to the SSO state in DirX
Access.

Identity Federation and Federated Authentication
Identity federation is a set of standards and technologies that allow
partner organizations to establish
trust relationships regarding eachother’s security policies and infrastructure, and then allow or denyaccess to resources based on this
DirX Access V9.1 | 3

trust.
Identity federation enables for the
secure sharing of digital identities
and login sessions across security
domains. It facilitates secure andseamless online collaboration by
providing safe access to partner
resources without the need for re-authentication and permits partners totrust and share identity information
for authentication and authorization
without the need to create and maintain it at each partner site.
Identity federation can• Cut the cost and complexity of
online collaboration by eliminating
the need for multiple user profiles.
• Deliver a positive user experiencethrough cross-domain SSO.
• Improve productivity by providing
secure, convenient access to theresources of trusted partners.
• Interoperate with other standards-compliant federation solutions.
In DirX Access, identity federation
extends the core services of authentication and authorization to the virtual enterprise.
Federated authentication is theprocess of transferring information
regarding authentication state froman identity provider to a service provider or relying party in a different
domain.
DirX Access supports federated
authentication according to SAML
2.0, WS-Federation, and OpenID
Connect 1.0.
In contrast to the concept of initialauthentication, federated authentication does not require that eachuser has a corresponding uniqueuser account at the side of the service
provider. Instead, the identity provider typically assigns roles to users
and the service provider grants ordenies access to a resource according to the roles from the security
assertion statement. In this way, allinformation necessary to perform
authentication (such as digital identity, authentication credentials, etc.)
are managed locally at the identity
provider but the final access decision
remains in the sole responsibility ofthe service provider. SSO is also provided for federated authentication
scenarios.
SAML based Federation
In the case of SAML-based federation,
DirX Access uses Security Assertion
Markup Language (SAML) assertions
to represent identities in federated
4 | DirX Access V9.1

SP
SP

IdP
Identity Provider Proxy
SAML 2.0
Identity
ProviderSAML 2.0
Service
Provider

SP

IdP
IdP
IdP

Figure 2 - DirX Access - SAML Proxying IdP in a Hub/Spoke Scenariotransactions.
DirX Access supports both SAML 2.0
federation scenarios:• Service provider-initiated: In thiscase, the user attempts to accessa resource on a federated domain
without first authenticating. The
remote site then redirects theuser to the identity provider forauthentication. If authentication iscompleted successfully, the user isreturned transparently to the destination site for authorization and,ultimately, for access to the desired
resource.
• Identity provider-initiated: In thiscase, the user first authenticates in
the local domain and then makesa request for a service or resource
located on a federated domain.
In both scenarios, DirX Access canrepresent the identity provider thatauthenticates the user, or the service
provider that owns the resource andrelies on the source site’s authentication.
DirX Access supports the following
SAML 2.0 profiles, associated message protocol flows and bindings
according to the SAML 2.0 conformance requirements document:• Web Browser SSO profile with
AuthnRequest message from SP
to IdP via HTTP redirect or HTTP
POST binding• Web Browser SSO profile with IdPResponse message to SP via HTTP
POST or HTTP artifact binding
including Unsolicited Responses(IdP first)• Identity Provider Discovery profile with cookie setter and cookie
getter messages via HTTP binding• Single
Logoutprof ilewith LogoutReques t and
LogoutResponse messages via
HTTP redirect, HTTP POST, HTTP
artifact or SOAP binding• Artifact Resolution profile with
ArtifactResolve and ArtifactResponse message via SOAP

binding• Assertion Query/Request profile
with authentication query, attribute query, authorization decision
query and request for assertion
by identifier messages via SOAP
binding• Basic Attribute profile• X.500/LDAP Attribute profile• UUID Attribute profile• XACML Attribute profile
DirX Access supports the following
SAML protocols:• Authentication request protocol• Artifact resolution protocol• Single logout protocol• Assertion Query and Request Protocol with authentication query,
attribute query, authorization decision query and request for assertion by identifier elements
Request/response objects can besigned (enveloped XML signature).
DirX Access supports SAML assertions with the following contents:• Authentication statements• Attribute statements• Authorization decision statements
Assertion objects and protocol
objects can be signed (enveloped
XML signature). SAML assertions,
NameIds, and attributes can beencrypted.
DirX Access can include environmental information – for example,
solution-specific security environments like information on network
trust level and device types - into the
SAML assertions.
DirX Access supports SAML metadata import and export, which
addresses the mutual configuration that needs to be establishedbetween an identity provider and aservice provider.
SAML Proxying
DirX Access supports SAML proxying

based on the SAML 2.0 specification.
In SAML proxying, identity providers
can proxy an authentication requestfrom a service provider to a different
identity provider that has alreadyauthenticated the user or is capableof authenticating the user, enabling
the delegation of initial user authentication in SAML Web SSO federationfrom a local SAML identity provider
endpoint to external SAML identity
provider endpoints.

Identity Federation with OpenID
Connect

A proxying identity provider is acombination of a traditional SAML
authentication identity provider(implementing SAML SingleSignOnService in particular) and a traditional
service provider (implementing
SAML AssertionConsumerService).

OpenID Connect 1.0 is becoming awell-established alternative for SAML
protocol as it is currently supported
by major service-providing market
players, such as Google, Facebook,
etc. Based on a more lightweighttechnologies (RESTful web services
and JSON format), OpenID Connect,
and OAuth-based protocols in general, can lower the communicationand performance demands, while
preserving the functional and security aspects of the other federation
standards.

With SAML proxying:• Multiple proxying identity providers can be configured between
the service provider and the actual
identity provider.
• A proxying identity provider can be
configured to connect to multiple
identity providers and/or to multiple service providers. In this configuration, the proxying identity
provider serves as a hub/bridge/
gateway in a hub and spoke identity federation model, allowing foreasier management of configuring
trust for a large number of identity
providers and service providers ina federation scenario.
Proven SAML 2.0 Interoperability
DirX Access passed Liberty Alliance
SAML 2.0 interoperability testingin 2009. DirX Access participatedin the third Liberty Interoperable™
full-matrix testing event for SAML 2.0
together with eight other products
from different vendors and demonstrated that DirX Access fulfills thestringent test criteria for open, secure
and privacy-respecting federated
identity management.
Preconfigured SAML Service
Providers
DirX Access supports preconfigured SAML service providers. Thisfunctionality allows administrators to easily establish SAML-based
interoperability between the DirX
Access identity provider and wellknown cloud service providers such
as Google Apps, Citrix ShareFile, Microsoft Office 365 and Salesforce.com
with out-of-the- box configurationsdelivered with DirX Access. It also
allows for parameterizing provider
instances and creating custom templates for other preconfigured service providers and identity providers.

OpenID Connect 1.0 Implicit Flow

DirX Access supports the core specification of the OpenID Connect
1.0 Standard. OpenID Connect 1.0
is a simple identity layer on top of
the OAuth 2.0 protocol. From the
OpenID Connect stack of standards,
DirX Access supports additionally
the OpenID Connect Dynamic Client
Registration Protocol and OpenID
Connect Discovery 1.0.

OpenID Connect 1.0 Authorization Code Flow
In OpenID Connect 1.0, a client (webapplication) wants to get a federated identity of an end-user fromthe authorization server, represented
by DirX Access. The end-user has anopportunity to express its consent
with the identity information being
provided to the client. The specificsof the authorization code flow arebasically twofold: the client securely
authenticates to the authorization
server; therefore, a trust is established, and the authorization server
can share information that shall be
not disclosed to anyone else, andeven the end-user is not able to learn
the shared information. This flow issuitable for clients that can securely
maintain their credentials, such as
web applications.

Contrary to the authorization code
flow, the implicit flow does not perform any client authentication. The
federated identity information may
be exposed to anyone with access tothe end-user’s browser. This flow issuitable for clients implemented in abrowser using scripting languages.
OpenID Connect Dynamic Client
Registration
In an environment where the web
applications (clients) requiring thefederated identity often changes andtheir overall count might easily surpass tens or hundreds, the management of the bounds between themand the authorization services might
get complicated. These bounds are
represented by server and client
metadata documents. DirX Accesspublishes the metadata of all configured authorization servers in a standardized way to be accessible by any
potential client. In the opposite direction, it employs the dynamic client
registration approach that enables
to automate the registration of newclients or update of the metadata forthe existing ones. The metadata canbe manually managed by the DirX
Access administrators to reflect any
client specifics.
However, to achieve a state with thehighest possible automation, DirX
Access wires a fine-grained configurability into the registration process.
At the end of the registration process,the client is assigned certain permissions at the authorization server,e.g., what identity information it canrequest, which flows it can perform,
or what security level it achieves. The
way of ensuring only the trusted clients may ask for al- lows permissions
is achieved via a delegation of thetrust. Before a client registration, an

DirX Access

OpenID Connect
Identity Provider

used for Authentication with OpenID
Connect and for Authorization

OpenID Connect

OAuth Client Endpoint

nnect

ID Co

Open

ID
en

t

ec

nn

Co

SSO Service

Op

DirX Access PEP

DirX Access
OpenID Connect
IdP

IT Resources
Accesses Resources

Authenticates atUser

Web Browser

Figure 3 - SSO with Social Identities based on OpenID Connect

DirX Access V9.1 | 5

authentication process must occur
first. The authentication may be performed by any entity known to DirX
Access and the permissions given tothis entity determine the permissions
given to the subsequently registeredclient. In a real-world scenario, theadministrator of the authorization
server may contractually appoint an
administrator at the customer’s side.
This administrator will be given rights
to automatically register clients withcertain permissions, according to theeverchanging demands of its environment.
Described metadata management
holds generally for any OAuth-based
standard.
DirX Access as OpenID Connect
1.0 Client
Figure 4 shows a single sign-on scenario based on OpenID Connect
where users authenticate with theirsocial identities from systems such
as Google, Salesforce etc. to access IT
resources that are protected by DirX
Access. In this scenario DirX Access isused for authentication via OpenID
Connect and for authorizing accessthe IT resources in a service provider
deployment.
Federation with Microsoft SharePoint
DirX Access provides identity federation with Microsoft SharePoint by
supporting the WS-Federation Passive Requestor Profile for authentication in SharePoint. Other applications
that support WS-Federation Passive
Requestor Profile can be connectedin the same way.
In this scenario, Microsoft SharePoint
supports trusted Identity Provider
authentication for SharePoint applications in the role of the Service Provider.
DirX Access implements the necessary functionality of both Identity
Provider and Security Token Service
for the authentication, using WSFederation Passive Requestor Profile.
Identity Federation and Cloud
Computing
DirX Access provides SSO for cloudbased applications or for SaaS tosecure access in a cost-efficient andreliable manner. Federation standards such as SAML and OpenID
Connect are being used for authentication of users to off-premises applications (SaaS or cloud-hosted).

6 | DirX Access V9.1

HTTP / REST / other

ClientSecurity Subjects

Yes/No/< doThis >Protected

PEP

Authorization
Service

Context
Handler

Resource

Cliente.g. Application
Authorization
Web Service

PDP

REST

PolicyFinderPIP

QuerynativePolicy Service

DirX Access Manager
Web Application

PAP
LDAP

Policy Repository

PDP – Policy Decision Point
PEP – Policy Enforcement Point
PIP – Policy Information Point
PAP – Policy Administration Point

Figure 4 - DirX Access – XACML based authorization
Inter-protocol Proxying
Thanks to the architecture of
DirX Access, it is possible to proxy
between different identity federation
protocols, OAuth to SAML, etc. If a
SAML service provider (SAML SP) / an
OpenID Connect client (OIDC client)requests federated identity fromthe SAML identity provider (SAML
IdP) / OpenID Connect authorization
server (OIDC AS), either an authentication of the end-user is invokedor the SSO mechanism is used (theinformation on which is also basedon some initial authentication). Any
authentication method can be used,
including the identity federation
ones. During the authentication, theDirX Access role is switched fromthe SAML IdP / OIDC AS to SAML SP/ OIDC client, a federated identity is
retrieved from the third party, translated into the authenticated session
which is in turn used to provide thefederated identity to the originally
requesting SAML SP / OIDC client.

Authorization and Entitlement Management
DirX Access offers two fundamentally different types of authorization
mechanisms. For the enterprise environment, authorization is provided as
an external, centralized, policy-based
access control service that allows forthe “up front” definition of a comprehensive set of access control policies
and then grants or denies access toresources based on these policies.
This approach is represented by the
XACML-based authorization service.
With the raise of the IoT environment,
DirX Access incorporated a service
able to protect resources owned bythird parties. Contrary to the centralized policy declaration, here, eachowner declares policies for its own
resources, while DirX Access subsequently manages the authorization

process invoked by any requestor.
This approach is based on theUser-managed Access 2.0 standard.
Both approaches are then independent and may or may not be
employed in the DirX Access installation according to the chosen configuration.

Enterprise Authorization
Based on the XACML (eXtensible
Access Control Markup Language)
standard from OASIS (Organization
for the Advancement of Structured
Information Standards), access policies can be defined according to theauthorization model that best suits
the environment.
For example, a role-based access
control (RBAC) model defines accesspolicies based on the roles assigned
to a user, while attribute-based
access control (ABAC) defines accesspolicies based on attribute values,
and with discretionary access control (DAC) access policies are definedby the owner of an object. The owner
decides who is allowed to access theobject and what privileges they are
granted.
Policy-driven authorization has many
advantages. Access control policy
definition and management is performed outside of the individual
application and removes the need forindividual application access control
logic. It makes access policy creation
an initial task rather than an ongoing
one, simplifies the administration ofaccess rights to multiple Web applications and resources, and provides
for the consistent application ofaccess rights and enforcement of
security policies over time.
DirX Access uses XACML 1.x/2.0/3.0
as the underlying authorization technology and supports the following
authorization models:• Arbitrary, application-defined
authorization models . Any
authorization model that can be
expressed as valid XACML objects
can be used. The actual policy content is form-free if policy syntax
requirements (well- formedness,
validity) are met.
• An RBAC authorization model,
allowing or denying access to
Web services and Web application resources and the resourcesof other applications based on therole held by the requesting user
within the organization. As people
come and go in the organization,
they can be assigned the roles thatmatch their job descriptions andresource access requirements.
Once effective business roles aredefined in DirX Access, administrators can quickly and efficiently
match users with the access rights
they need, without fear of forgetting a crucial resource. This authorization model is constrained by
the RBAC profile of XACML; thepolicies that can be expressed inthis authorization model need tocomply with this dedicated profile.
Authorization in DirX Access is delivered by the following building blocks(see figure 4):• PEPs (policy enforcement points),
deployed as plug-ins to Web andWeb application servers or otherapplications, process accessrequests, send authorization decision requests to PDPs and provide
the authorization decision to theirenvironment. Some PEPs enforce
the PDP authorization decision
themselves, while other PEPs justinform their environment aboutthem.
• PDPs (policy decision points), provided as part of the DirX Access
Server, render authorization decisions for access requests sent from
PEPs. They base their decisions on
authorization policies obtained
from PAPs.
• PAPs (policy administration points)
are authorization policy authorities
that allow administrators to create,supply and maintain authorization
policies. The PAP is represented by
the policy service in a DirX Access
Server. This service can be used via
the DirX Access Manager (authorization policies complying to the
ABAC or RBAC model) or the DirX
Access Provisioning Web service(authorization policies complying
to the RBAC model). Working with
the PAP is subject to authorization
and authentication through DirX
Access.

• PIPs (policy information points)
can be used to access information
about the application environmentthat may be required in evaluating
policy decisions. PIPs can also provide information on the subject orresource involved in the request.
DirX Access supports dynamic
access control/authorization withthe help of attribute finders, which
provide the PDP with configurable
information for access decisions. All
information contained in the authenticated session (JAAS subjects) canbe used; for example, the user LDAP
attributes, SAML assertion attributes,
OAuth user profile data, applicationand environment-specific attributes
passed by the PEP to the server(client device identification, application information), etc.
In addition, DirX Access reacts in realtime to modification of user records;
for example, by revoking accesswhen user attributes are changed.

Federated Authorization
DirX Access supports the OAuth 2.0
Authorization Framework and a setof OAuth 2.0-based standards suchas specifications for User-Managed
Access (UMA) 2.0, OAuth 2.0 Token
Introspection (RFC 7662) and OAuth
2.0 Dynamic Client Registration Protocol (RFC 7591). For a complete list,
please, see the Supported Standards
section.
OAuth 2.0
DirX Access supports the OAuth
2.0 Authorization Framework for
authorization in identity federation scenarios. OAuth 2.0 defines aresource authorization protocol thatallows resource owners to delegate
resource access rights. This enables
sharing resources across organizational boundaries without sharing
user credentials. To support thisuse case, DirX Access provides both
OAuth client functionality and OAuth
authorization server functionality.
DirX Access can be configured independently or in conjunction withbrowser-based SSO for either an IdPor an SP deployment:• In an SP deployment, the OAuth
client federation endpoint client
requests and uses the access token
to access the protected resources• In an IdP deployment, the OAuth
server federation endpoint can beused to authenticate and provide
the access token with associateduser information.

User-Managed Access (UMA)
The focus on authorization in an IoTenvironment (and multiple resource
owners in general) is represented
in DirX Access by an authorization
service implementing the UMA 2.0
standard. This standard enables todelegate the complexity of authorization in systems managing, e.g.,
medical records, bring-your-owndevice policies, user-uploaded
resources, etc. DirX Access plays therole of the Authorization Service (AS)in such scenario and the connected
systems the role of Resource Services (RS). It provides a RESTful interface enabling the resource owner todeclare any resource-related policies(typically in a form of access controllist) which are subsequently used by
the AS at the time any requestor asks
for the protected resource. See, that
all the burden is truly put at the AS as
the only information the RS knows is
the requested resource identifier andaction.
A true power of the AS is the ability to
manage resources for multiple RSs.
The relationship between RS and AS
is established via the OAuth-specificmeans, hence, DXA can automate
also this process providing a perfectsolution for the aaS paradigm.
DirX Access supports the following
UMA-related specifications:• User-Managed Access 2.0 Grant for
OAuth 2.0 Authorization – a means
for a client representing a requesting party to gain access to a protected resource asynchronously
from the time a resource ownerauthorizes access.
• Federated Authorization for
User-Managed Access 2.0 – ameans for an UMA-enabled authorization server and resource server
to be loosely coupled, or federated,in a resource owner context.

User Management
Initial authentication of users
requires that identities are managed
in an LDAP directory. DirX Accesssupports two types of directories forthis purpose: external user directory,
and own managed user tree.
The external user directory is thestandard repository for storing of theuser accounts with its own schema,
for example, inetOrgPerson, and assuch it is expected to be managed by
an appropriate external tool (e.g., DirX
Identity). DirX Access is configurable
in the way it can use arbitrary LDAP
attributes for its authentication andauthorization needs.

DirX Access V9.1 | 7

Once authenticated, the full user
record/attributes can be used in federation or authorization scenarios(issuing SAML assertions, releasing
OAuth user profile data, evaluating
authorization policies, etc.) using
user data from arbitrary LDAP repositories.
The own managed user tree is a
repository storing predominantly
the user information necessary for
configured authentication methods, such as FIDO credentials, OTP
callback addresses, etc. This repository is managed by DirX Access itself,
via the SCIM 2.0 standard. The SCIM
2.0 resource structure is furthermore
extended to be able to manage theuser-specific data.
For more complex tasks, suchas assigning user attributes andprivileges, integrating multiple
directories, user databases, andapplication-specific repositories, it
is recommended to use an identity
management solution such as DirX
Identity. DirX Identity also provides
workflow-based user self-registration and self-management functionality as well as many other advanced
identity management functionalities.

Policy Management
Policy management in DirX Accesscomprises functions to create,
modify, delete, and view authorization and authentication policies
based on the XACML standard.
In DirX Access, administrative policies govern the administration of
DirX Access, and business policies
govern the access of users to the protected resources.
Authentication policies enforce theuse of specific authentication methods for different system resources.
Authorization policies apply authorization rules controlling actions onprotected resources.
Fine-grained authorization policies
help to define the level of granularity needed for authorization. They
consider the properties of requested
resources (such as security classifications) and requesting subjects (suchas usernames, group memberships
or role assignments) to enable authorized access to resources and denyunauthorized access.

Securing Web Applications
Access management solutions were
initially focused on securing accessto Web applications and Web con-

8 | DirX Access V9.1

tent behind eBusiness, eGovernment, and eShop portals. To this end,
DirX Access WAM capabilities apply
the concepts of external, central, policy-based authentication and authorization services, identity federationand SSO to provide secure, convenient, and reliable access to multiple
Web applications with one authentication step.
The DirX Access PEPs that secure
Web applications can be classified
as protocol stack extension PEPs,
agent PEPs and application PEPs. In
addition, custom PEPs can be created based on the client SDK or by
the DirX Access Web services.
Protocol stack extension PEPs
reside in protocol stacks. The mostcommon examples are the HTTP
stack PEPs (Web PEPs) like the ones
for Apache Web Server, Apache
Tomcat or Microsoft Internet Information Server. They integrate withthe down-stream applications thatthey protect mainly through header
injection. Via header injection, datafrom various sources can be madeavailable to applications, e.g., userand session-related data as well as
data from arbitrary LDAP repositories.
Agent PEPs make use of the extensibility interfaces of the Web Serveror Application Server to protect theapplications that run in these servers. The DirX Access Agent PEP for
the Microsoft Internet Information
Server (IIS) provides event handlersthat handle the IIS authentication
and authorization requests of the IIS
server.
Application PEPs can be provided for
applications that support standard
or published interfaces. One important example is servlet applications,which can be protected individuallyby the DirX Access servlet filter PEP.
Other examples are cloud-native
applications that are running in cloud
application platforms such as Cloud
Foundry. These applications can beprotected by the DirX Access Cloud
Foundry PEP. Applications that do
not provide such integration points
can be protected with a custom-developed PEP built with the DirX
Access Client SDK.

Security Web Services
The problem of externalizing andcentralizing application-specificsecurity also applies to Web services-based SOAs. When migrating
applications to run as discrete Web
services, how do you handle the individual (and usually unique) security

logic and data that is present in eachapplication?
DirX Access responds to this challenge by providing its security
features as out-of-the box Web services for deployment in Web services-based SOAs. Businesses canthen add security logic as well-defined, published Web services foruse by any business process service
running in a Web service-based SOA.
DirX Access provides the Web services based on two technologies
RESTful and SOAP WS. The RESTful
WS are build according to the Open
Data Protocol (OData) Version 4.0
standard issued by OASIS. These
interfaces are also described using
the OpenAPI 3 format to ease theintegration with their clients.
DirX Access provides the following
off-the-shelf Web services:• The SSO Web service, which is asingle point comprising all thenecessary functionality to evaluate
a request: authentication (initial,
step-up, risk-based), authorization,
SSO, request/response injection.
• The Federation Web service, which
provides an OASIS WS-Trust security token service (STS).
• The Provisioning Web service,
which provides the ability to provision DirX Access with users,
groups and organizational units,
and to control the assignment of
those objects to roles. It is basedon the OASIS SPML V1.0 and V2.0
standards.
• The Configuration Web service,
which is used to configure the DirX
Access system.
• The System Actions Web Services,
enabling components deployment, keystore management, etc.

Administration
Administrative responsibilities reflectbusiness structures so that companies can place the managementof users, groups, and policies foraccess to resources with someone
close to the demands of a particularbusiness line. DirX Access provides
methods for flexible, secure delegation of administrative responsibilities
to respond to temporary changes
in personnel and shifts in organizations and processes and support
the business-agile enterprise. DirX
Access provides Web-based administration tools that permit administrative activities to run in parallel for
fast, efficient deployment of accesspolicies across the virtual enterprise.
If there is a need for more complex

identity management and provisioning activities, DirX Access canbe seamlessly integrated with DirX
Identity or cooperate with otheridentity management solutions.
Access control for administration
uses the same authentication andauthorization mechanisms as access
control for protected organizational
resources.
DirX Access administration is performed through the DirX Access
Manager (see figure 5), a Web-based
administration tool that allows
administrators to perform a varietyof tasks, such as:• Creating business roles.
• Creating authentication policies
using a resource tree.
• Configuring risk-based conditions
and associated data collectors.
• Creating authorization rules andpolicies using a resource tree.
• Setting authorization conditions,such as the time of day, authentication method, assurance level, or
the IP range required for access.
• Assigning policies to roles.
• Configuring XACML ABAC policies.
• Configuring the internal representation of authenticated subjects.
• Configuring the SAML assertionsof authenticated subjects.
• Configuring federation.
• Configuring servers.
• Configuring PDPs.
• Configuring PEPs.
The DirX Access Manager is a single-page web application utilizing
RESTful interfaces published by DirX
Access Server. Namely, the SysActions RESTful Web service enabling
to deploy any DXA component or
web application and the Configuration RESTful Web service enabling tomanage configuration and policies.

Multi-Tenancy
To support multi-tenancy, multiple instances of DirX Access can be
deployed. Each instance represents
a tenant with specific configuration
separated from other tenants. This
allows serving multiple client organizations (tenants) with one single
installation of the software. DirX
Access provides means to create
additional instances / tenants.

Audit
To prove compliance with an increasing number and complexity of business and privacy regulations, theDirX Access Audit service provides
complete transaction accountability across the virtual enterprise. The
system:• Audits transactions both within
and across security domains.
• Logs all security events for proof ofactivity; for example, the result ofauthentication and authorization
requests or password and policychanges.
All authorization requests for a given
transaction can be correlated to previous authentication events; therefore all transactions can be traced
back to their origins. This design
applies to all relevant system features(authorization, authentication, identity federation, user management,
policy and configuration management).
Audit data generated by the DirX
Access audit service corresponds
directly to the actions of identifiable
and authenticated users. Actions
recorded for each user include:• Authentication (who, when, how)
• Authorization (who, when, forwhat)

policies and user data as XML files
through various Web services. Thisfeature can be customized andtransformed, for example, by XSLT tocustom reports.

Logging
DirX Access logging records internal
system operations for problem diagnostics and debugging. The amountof information each server generates
can be controlled by restricting its
logs to a given level.

System Monitoring
DirX Access Services containers support monitoring via Java MBeans.
MBeans provide a Java-platformstandard method for monitoring asoftware system. MBeans are handled by Java technology called JavaManagement Extensions (JMX).
DirX Access MBeans provide live data
about the status of the containers
as well as usage statistics, such as,
among others,• Numb er
requestsofauthentication• Number of authorization requests• Session management (for example, session lifetime, idle timeout)• Number of SAML assertion issuance requests• Account and password management (for example, changes, expiration time reached)

Nagios Support• Policy management (for example,
role, authentication and authorization policy creation and modification)• Configuration events
DirX Access provides an audit externalization interface that supports
custom implementations of audit
events processing via plug-ins. The
following implementations are provided with the product:• An implementation based on
Log4J which uses Log4J appenders (for example, for console, file,
database, syslog, and other items)
to process DirX Access audit
events. This is the default audit
plug-in provided by DirX Access.
• Out-of-the-box integration to the
DirX Audit product.
DirX Audit can be used for centralized, secure storage, analysis, correlation, and review of identity- andaccess-related audit logs and for
creating reports. DirX Audit is partof the DirX product suite and can beordered separately.
DirX Access provides for the exportof its deployment, configuration,

MBeans published by DirX Accesscomponents can be used by a variety of monitoring tools and systems.
Especially, DirX Access allows integration with Nagios, one of the widespread monitoring systems via thethird-party tools JNRPE, check_nrpe
and check_JMX, which provide quite
straight-forward means for monitoring Java processes using MBeans.

DirX Access Architecture
Many third-party business applications in the enterprise can use DirX
Access for access management andenforcement; for example, portals,
Web servers, application servers,
and other ap- plications. They can bebroadly structured ac- cording to the
Client, Web, Application, and Datatier. DirX Access typically integrates
into the Web and Application tiers.
Depending on the technology ofthese integration tiers, one may use
the DirX Access off-the-shelf capabilities (PEPs and federation endpoints).
DirX Access integrates with the applications it protects via standard federation protocols, or through capturing
agents (referred to as PEPs - policy
enforcement points) deployed asplug-ins to Web and Web application
DirX Access V9.1 | 9

servers or other applications. They
act as DirX Access Server clients,
mediating the authentication andauthorization process, enforcing theaccess decisions of the server, andproviding the user browser and thedownstream applications with session and state information. This setup
also includes reverse-proxy configurations.
The DirX Access Server provides thecore security services — authentication, authorization (PDP - policy
decision point), SSO, federation,
policy, configuration and others —to the PEPs, mediates the access to
the LDAP repositories, exposes theservices as Web services and/or federation services to third-parties andprovides the Web-tier logic for the
Web-based management interfaces.
The PDP access decisions are driven
by the XACML-based authorization
policies, which are managed by thepolicy administration point (PAP).
The PAP is implemented by thepolicy service in the server. It can beused through a Web-based GUI provided with the DirX Access Manager.
The policy information points (PIPs)
are used to access information about
the application environment or on
the subject or resource involved in
the request.
DirX Access uses LDAP directory
servers to store user, configurationand policy data, and DirX AccessCache Server to facilitate the distributed nature of the system, with thefocus on data caching and persisting.
The DirX Access architecture can be
structured in tiers as follows:
Client tier:• DirX Access PEPs
Server tier:• DirX Access Servers providing
security services• DirX Access applications such asfederation endpoints, Authentication Application, DirX Access Manager, and Web services
Data tier:• Directory servers used to store
user, configuration, and policy
data for DirX Access Cache Servers
to cache and persist the distributed system information, such as
extended SSO information, longlived federation data, etc.
DirX Access services and applications
are uniformly deployed in ready-touse OSGi-based container.

10 | DirX Access V9.1

Figure 5 - DirX Access Manager - Example of Administrator User Interface

Figure 6 presents the DirX Accessarchitecture and its integration
points in existing applications froma high-level component perspective.

Authentication Application allows
for context-aware authentication
based on, e.g., internal vs. external IP
address ranges to minimize risks.

Client Tier: DirX Access Policy Enforcement Points

DirX Access federation applications
provide endpoints for federated
identity management:

PEPs are plug-in components that
operate as a DirX Access client andthat provide policy enforcement
services (especially authorization
and authentication). They process
requests for resources and services,query the DirX Access Server for
authorization and authentication,and provide the decisions back totheir environment.
For integration purposes, DirX Accessalso supports the configuration ofarbitrary LDAP user objects that are
injected into the HTTP header for further use of the secured application.
Server Tier: DirX Access Applications
DirX Access provides the following
categories of off-the-shelf Web applications: DirX Access Manager, DirX
Access Authentication Applicationand federation applications.
DirX Access Manager provides anintuitive Webbased interface thatallows full or delegated administrators to manage the system (fordetails, see the Administration section of this document).
DirX Access Authentication Application is a DirX Access component
that performs initial user authentication on behalf of DirX Access PEP
and FEP components. The layout of
the user interface and the flow ofauthentication are customizable. The• The SAML service provider federation endpoint (SP FEP) provides afederation endpoint for SAML service providers• The SAML identity provider federation endpoint (IdP FEP) provides
a federation end- point for SAML
identity providers.
• The SAML identity provider federation endpoint supports SuisseId
and the SAML service provider
federation endpoint provides
support for SuisseID-enabled
identity providers. SuisseID is anational ID infrastructure projectin Switzerland. SuisseID follows auser-centric identity management
approach and extends the SAML
2.0 specification by user-centric
identity management features.
• The OAuth server federation endpoint represents the authorization
server side of the OAuth communication. An authorization endpoint is used by the client to obtain
authorization from the resource
owner via user-agent redirection.
A token endpoint is used by theclient to exchange an authorization
grant for an access token, typicallywith client authentication. A userinfo endpoint is used by the client
to exchange the access token for
identity data about the authenticated entity. The metadata andclient registration endpoint areused for metadata registration andexchange. And the policy management endpoints are used for managing the policies for resources
stored at connected resource
servers by the resource owners(employed by the UMA 2.0 authorization process).
• The OAuth client federation endpoint represents the client side of
the OAuth communication andis able to create a session in DirX
Access. The OAuth client federation endpoint works with any
OAuth 2.0 server such as Google,
Facebook, etc.
DirX Access Web Services
DirX Access provides the following
off-the-shelf Web services:• SSO Web service• Authentication Web service• Authorization Web service

Web and Application Server, Customer Applications
PEPs for Target Systems

User
Repository

DirX AccessCore Services

DirX AccessWeb Services

DirX Access
Applications

Authentication
Authorization
Administration
Audit

Authentication/SSO
Authorization
Federation
Provisioning
Configuration

SAML Endpoints
OAuth Endpoints

elements:• Authentication policies• Authorization policies (RBAC/
ABAC), including rule, condition,
and action components• Provisioning Web service• Authentication methods• Configuration Web service• Server configurations• System Actions Web service• Policy enforcement point configurations

The DirX Access services provide thecore functionality of the product,
including authentication and SSO,
authorization, administration andaudit services. This functionality isrealized using SOA principles andconsists of core and supporting services.
The DirX Access Server services areused through bundled Web applications, via standard protocols as wellas custom Web services.
Data Tier: Directory Server
DirX Access can use two different
LDAP directory servers in parallel,
one for user and one for policy/configuration and DXA-specific userdata.
Any standard LDAP directory witha schema suitable for user management (for example, InetOrgPerson object class) can serve as a user
repository.
DirX Access can supplement the user
record obtained from the user directory with information from otherstores using standard and/or custom-build attribute finders, which
are functionally comparable with
virtual directories.
Policy data includes the following

Web
Applications

Figure 6 - DirX Access - Architecture and Integration into Applications• Federation Web service

Server Tier: DirX Access Core
Services

Authentication
Application

OSGi Framework• Configuration data includes thefollowing elements:

For details, see the Security Web Services section in this document.

Web Browser• Federation endpoint configurations• Centralized component configuration parameters such as user
directory settings, templates toconstruct or interpret SAML assertions and other parameters
The LDAP directory server used for
configuration data is also used forstoring the user-specific data generated by DirX Access, RBA data, andseveral types of credentials, FIDO-related credentials, OTP credentials,
etc. If any of these use cases are configured to take place, the directory
server shall be handled accordingly
from the security perspective.
User management applications canbe integrated with the DirX Access
Server via its provisioning interface.
DirX Access can also use various
LDAP servers that are not part of the
DirX Access product delivery.
Data Tier: DirX Access Cache
Server
DirX Access Server can utilize any
number of DirX Access Cache Servers to enable distributed caching andpersistence. This is predominantly
necessary to support following features:• Extended SSO session information(such as inbound SAML Assertions
bound to the session),• Long-lived OAuth tokens (e.g.,refresh token)• Dis tribution of information
between servers (e.g., distributed
single logout in SAML)
Recommended deployment consists of one DirX Access Cache
Server collocated to each DirX Access
Server. However, this fully depends
on required high-availability features.
In an unstable and dynamic environment, DirX Access Server can shortterm operate without DirX AccessCache Server preserving the capability of providing the most-used features (e.g., SSO, initial authentication,etc.).

Reliability, High Availability,
and Scalability
To achieve maximum availability
and failover security as well as scalability, multiple, redundant DirX
Access Servers (and corresponding
DirX Access Cache Servers) can be
configured. DirX Access clients, e.g.,
PEPs, can perform load-balanced
access to the servers. Therefore, theDirX Access clients keep an internal
connection pool and a health index
of the multiple servers. Load-balancing is then handled internally usingthat connection pool. To complete
the fail-safe setup, the DirX Access
Server supports primary and secondary directory configuration for
failover deployments.
DirX Access uses a set of sophisticated mechanisms to recover fromnetwork component failures andprevent down time for users, including:• A distributed cache and persistence, based on DirX AccessCache Server components. The
distributed cache and persistence
enables the DirX Access Servers toshare and persist security objects.
• Load balancing between DirX
Access Servers based on a roundDirX Access V9.1 | 11

robin scheduling algorithm andserver stickiness.

in the third Liberty Interoperable™
full matrix testing event for SAML 2.0.

• A state-of-the-art operation recovery process using retries, retry
intervals and error thresholds.

For initial user authentication in
Web environments, DirX Accesssupports SSL/TLS, HT TP Basic,
HTML Form-based authentication
with username/password, one-timepasswords based on IETF RFCs, 4226
and 6238 and FIDO U2F, UAF, W3C
WebAuthentication (based on FIDO2
input).

Client Behaviour
Every application acting as a DirX
Access client in the system is
expected to have a corresponding
entry in the DirX Access configuration
store. This holds for both, the PEPs represented by PEP configuration
objects, and the standard-based federation clients (e.g., SAML SP, OAuth
client, etc.) - represented by the standard metadata objects. When a DirX
Access client initiates communication with a DirX Access Server, it must
provide an instance name. The configuration service uses this instancename to determine the appropriate configuration entry in the configuration store. This includes theaddresses of all DirX Access Servers
in a network, or a dedicated subsetof these servers associated with thisclient in a specific way.
When an application sends requests
to DirX Access Servers, the underlying DirX Access PEP transparently
performs load-balancing over theconfigured DirX Access Servers. It
also automatically creates serverconnections as required to process
its message traffic, up to its configured maximum. When this thresholdis reached, the DirX Access client continues to process its message traffic
using the available servers and connections.
LDAP Failover
Access to the LDAP directory configuration/policy and user repository is
crucial for DirX Access and is ensured
by switching to a secondary directory
server instance if the primary serveris unavailable. If a DirX Access Server
receives a timeout in response to any
directory operation, it will try using
the secondary instance instead.

Supported Standards
DirX Access supports the relevant
standards, protocols, and security
frameworks to provide its security
functionality and services:

For object security, DirX Access supports XML signature.
For key management, DirX Accesssupports PKCS and X.509/PKIX.
For communications, DirX Accesssupports HTTP, RESTful, SOAP andWS-*.

For intra-domain SSO in Web environments, DirX Access supports
Integrated Windows Authentication(SPNEGO/ Kerberos, NTLM), authenticated subject identifiers transferred
via HTTP cookie headers, and URL
rewriting.

For persistence and provisioning,
DirX Access supports LDAP, DSML
and SPML.

For cross-domain SSO and identity
federation in Web environments,
DirX Access supports SAML 1.x/2.0
especially SAML Web-SSO profiles, and WS-Federation Passive
Requestor Profile Version 1.0

DirX Access supports both IPv4 andIPv6 Internet Protocol.

For cross-domain SSO and identity
federation in Web services environments, DirX Access supports
WS-Trust.
The implementation of OAuth 2.0
Authorization Framework together
with the following extensions
enables DirX Access to be employedin almost any plausible federation
scenario:• The OAuth 2.0 Authorization
Framework (RFC6749)• The OAuth 2 .0 Authorization Framework: Bearer Token(RFC6750)• OAuth 2.0 Authorization Server
Metadata, https://tools.ietf.org/
html/draft-ietf-oauth-dis- covery06• OpenID Connect 1.0• OpenID Connect Discovery 1.0• OAuth 2.0 Token Revocation(RFC7009)• OAuth 2.0 Token Introspection(RFC7662)• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)• OpenID Connect Dynamic Client
Registration Protocol• OAuth 2.0 Resource Registration

For authorization and privacy, DirX
Access supports XACML 1.x/2.0/3.0,
XACML 3.0 Multiple Decision Profile
Version 1.0, XACML SAML Pro- file
Version 2.0, SAML 1.x/2.0, OAuth 2.0
and RBAC.

• Proof Key for Code Exchange(RFC7636)

DirX Access successfully passed theLiberty Alliance SAML 2.0 interoperability test in 2009 when it participated

For user-specific data provisioning,
DirX Access supports SCIM 2.0.

12 | DirX Access V9.1

For secure communication, DirX
Access supports SSL/TLS and WS-*
security.

• Federated Authorization for
User-Managed Access 2.0• User-Managed Access 2.0 Grant for
OAuth 2.0 Authorization

In Java environments, DirX Accesssupports JAAS, JACC, JCA/JCE, JGSS,
and JSSE.

System Requirements
Supported Policy Enforcement Points and Client SDK:
The following combinations are supported. Other PEPs may be available on request.
Microsoft Windows Red Hat Enterprise SUSE Linux EnterServer 2019 / 2022
Linux 7 / 8
prise Server 12 / 15
Web Server PEPs
Apache httpd V2.4 2)

Yes

Yes

Yes

Reverse Proxy (based on Apache httpd V2.4)

Yes

Yes

Yes

Apache Tomcat V8.5/9.0/10.0

Yes

Yes

Yes

Eclipse Jetty V8/9/10/11

Yes

Yes

Yes

Microsoft IIS 2)

Yes

-

-

Servlet Filter e.g. Tomcat, Jetty, etc.

Yes

Yes

Yes

Cloud Foundry

-1)

-1)

-1)

Yes

Yes

Yes

Servlet and Application-specific PEPs

Client SDK Support (Legacy Application PEPs)
DirX Access Client SDK for Java 8 or higher
1)

The Cloud Foundry PEP can be deployed into an existing Cloud Foundry Provider environment.

2)

PEPs are not part of this release, but are available on request or with the Service Pack.

DirX Access V9.1 | 13

System Requirements
Hardware• Intel server platform for Microsoft
Windows Server 2019 and 2022
• Linux

Supported LDAP Directories for
Configuration/Policy Data
DirX Access supports the following
LDAP directories (others on request):• DirX Directory V8.9/V8.10

Memory Requirements:
Main memory:

minimum 8 GB

Disk Space:		minimum 1 GB plus
disk space for data

Software
DirX Access Server
DirX Access Server as a Java application is supported on the following
platforms with latest patches/service
packs for the selected platform:• Microsoft Windows Server 2019(x86-64)• Microsoft Windows Server 2022
(x86-64)• Micros of t Windows S er ver
2019/2022 Active Directory / Active
Directory Lightweight Directory
Services (AD LDS)

Browser Support for the DirX Access Manager and Deployment
Manager• Microsoft Internet Explorer 11• Microsoft Edge

• SUSE Linux Enterprise Server 12(x86-64)• JNRPE Server, Version 2.0.5

14 | DirX Access V9.1

Manuals• Release Notes• Introduction Guide• Integration Guide

For Nagios Integration• VMWare ESXi, in combination withthe guest operating systems listed
above and that are supported by
VMWare ESXi.

All manuals are provided in English:

Arbitrary LDAPv3-compliant directory servers with user accounts
based on the InetOrgPerson object
class• Red Hat Enterprise Linux 8 (x8664)

Virtual Machine Support:

Documentation• Installation Guide• Firefox 71 or newer• Java SE Runtime Environment(JRE) 11 for the selected operating
system• English

Supported Directories for User
Data

• Red Hat Enterprise Linux 7 (x8664)• SUSE Linux Enterprise Server 15(x86-64)

User interface• Google Chrome 78 or newer• Nagios Core Version 4.0.8• JNRPE Plugins, Version 2.0.3
Supported PEPs and Application
Servers
These components are listed on theprevious page.

• Administration Guide

DirX Product Suite
The DirX product suite provides the basis for fully integrated identityand access management; it includes the following products, which canbe ordered separately.

DirX Identity
DirX Identity provides a comprehensive, process-driven,customizable, cloud-enabled, scalable, and highly available identity management solution for businesses andorganizations. It provides overarching, risk-based identity and access governance functionality seamlessly
integrated with automated provisioning. Functionality includes lifecycle management for users and roles,
cross-platform and rule-based real-time provisioning,
web-based self-service functions for users, delegatedadministration, request workflows, access certification,
password management, metadirectory as well as auditing and reporting functionality.

DirX Directory
DirX Directory provides a standards-compliant, high-performance, highly available, highly reliable, highly scalable,
and secure LDAP and X.500 Directory Server and LDAP
Proxy with very high linear scalability. DirX Directory canserve as an identity store for employees, customers, partners, subscribers, and other IoT entities. It can also serve asa provisioning, access management and metadirectory
repository, to provide a single point of access to the information within disparate and heterogeneous directories
available in an enterprise network or cloud environment
for user management and provisioning.

DirX Access
DirX Access is a comprehensive, cloud-ready, scalable,
and highly available access management solution providing policy- and risk-based authentication, authorization based on XACML and federation for Web applications
and services. DirX Access delivers single sign-on, versatile authentication including FIDO, identity federation
based on SAML, OAuth and OpenID Connect, just-intime provisioning, entitlement management and policy
enforcement for applications and services in the cloud or
on-premises.

DirX Audit
DirX Audit provides auditors, security compliance officers and audit administrators with analytical insight andtransparency for identity and access. Based on historical identity data and recorded events from the identityand access management processes, DirX Audit allows
answering the “what, when, where, who and why” questions of user access and entitlements. DirX Audit features
historical views and reports on identity data, a graphicaldashboard with drill-down into individual events, an analysis view for filtering, evaluating, correlating, and reviewing of identity-related events and job management forreport generation. With its analytical features, DirX Audit
helps enterprises and organizations to ensure sustainable
compliance and provide business intelligence for the riskbased identity and access management processes.

Eviden is a registered trademark © Copyright 2023, Eviden SAS – All rights reserved.

DS-230613-GW-DirX_Access_V9.1_Datasheet_EN