Sign&go Architecture Guide

Architectures &
Concepts
Contacts
ILEX
51 boulevard Voltaire
92600 Asnières-sur-Seine
FRANCE
Telephone : +33 (0)1 46 88 03 40
Fax : +33 (0)1 46 88 03 41
www.ilex-international.com
support@ilex-international.com
Legal Information
Meibo, Meibo People Pack, Sign&go and Sign&go Santé are registered trademarks of Ilex.
All other trademarks mentioned in this document are the property of their respective owners.
This document is provided for information purposes only. Ilex provides no guarantee nor accepts any
liability for the information contained in this document. All specifications or information given in this
document are subject to modification at anytime without prior notification.
In accordance with article L. 122-4 of the Code de la Propriété Intellectuelle (French intellectual property
law), any full or partial reproduction, representation or distribution of this document by any means
whatsoever, without the express permission of Ilex, is prohibited and constitutes a breach of the law that
can result in prosecution under Articles L. 335-2 and subsequent articles of the Code de la Propriété
Intellectuelle (French intellectual property law).
Copyright Ilex 2015. All rights reserved.

Sign&go
TABLE OF CONTENTS
I. OVERVIEW OF SIGN&GO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
1. What is Sign&go?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Securing access to information systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Sign&go, access control and secure SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Sign&go, first ''Global SSO'' solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. When should Sign&go be used? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Architecture of Sign&go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Functionality of Sign&go. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Authorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Auditing access to company resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
II. ARCHITECTURE TYPES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

1. Overview of Sign&go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1. Principle of Sign&go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2. Components of Sign&go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2. Securing external access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1. Simple configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2. High availability configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3. Securing internal access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1. Web Proxy SSO architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2. Filter based Web SSO architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3. Multi-site architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4. Identity Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
III. CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

1. Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.2. Walk-through of an authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.3. Case example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2. Authorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2. Walk-through of access to a protected resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3. Case example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3. SSO strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2. Walk-through of an SSO strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Ilex 5
Sign&go
4. Secondary credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2. Walk-through of credentials management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4. Credentials management interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
IV. ADVANCED CONCEPTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

1. Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.4. Case examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2. Directory mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3. Multi-domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3. Walk-through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4. Case example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4. SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2. Usage context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4. Walk-through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5. Case example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5. Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2. Case examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6 Ilex
Sign&go
Chapter 1
Overview of Sign&go
In this chapter:
 What is Sign&go? (page 9)
 When should Sign&go be used? (page 11)
 Architecture of Sign&go (page 13)
 Functionality of Sign&go (page 15)
Ilex 7
Sign&go
8 Overview of Sign&go Ilex

Sign&go
1. What is Sign&go?
In this section:
 Securing access to information systems (page 9)
 Sign&go, access control and secure SSO (page 9)
 Sign&go, first ''Global SSO'' solution (page 9)
1.1 Securing access to information systems

IT systems evolve and the data critical to a company is now accessible by many of its employees.
In order to remain market leaders, companies need to get the most out of their information
systems, by implementing identity management projects.
Indeed, the provision of these applications - key to customers and partners alike, mobility, remote
working and the dynamism of the company are all factors requiring rigorous identity and access
management.
In order to manage the risks incurred in terms of security and to respond to new regulatory
requirements, rationalisation of the management of identities and the imposition of access
controls in accordance with the company's security policies are required.
1.2 Sign&go, access control and secure SSO

By centralising the management of authorisation and authentication, Sign&go responds to this
requirement in a clear and unique way securing all of your internal and external access
requirements.
Moreover, deployment of Sign&go presents numerous advantages:
 The access to applications is simplified and requires only one authentication by the
users (SSO - Single Sign On)
 The use of strong authentication (smart cards, USB keys) can be applied generally and
adapted to the resources being accessed
 The security policies defined within the company's repositories can be applied
 All attempted accesses and authorisations are archived
Sign&go is a security solution conceived for rapid and flexible integration into the most demanding
eBusiness architectures.
Compatible with leading databases and directories available on the market, Sign&go directly
exploits the company's data repositories.
Finally, by respecting Identity Federation standards, Sign&go guarantees a lasting investment in
an open and interoperable solution.
1.3 Sign&go, first ''Global SSO'' solution

Today, the key issue is to implement a new technology adapted to various work environments
while serving business productivity.
Sign&go, the new generation SSO, satisfies these imperatives by providing both Web SSO and
Enterprise SSO within a common architecture and administration. Sign&go, is the first Global
SSO solution.
Ilex Overview of Sign&go 9

Sign&go

Sign&go
2. When should Sign&go be used?
Sign&go is the security solution to implement as soon as your company finds itself faced with any
of the following situations:
 Internal applications being made available to partners, customers or suppliers
 Implementation of security policies
 Deployment of strong authentication systems
 Unique authentication of users of the company's applications (SSO)
 Auditing access to all IT applications

Sign&go

Sign&go
3. Architecture of Sign&go
Sign&go allows managing Web SSO and Enterprise SSO or, in other words,
''Global SSO''. Most of the concepts mentioned in this guide are common to the
Web SSO solution and eSSO. However, this guide refers only to the specifics of
the Web SSO architecture.
On average, an employee possesses between 4 and 10 different user accounts. This means that
there are probably just as many passwords to remember, with as many potential security lapses.
Management of these passwords by the helpdesk penalises the user's activity (blocked accounts,
forgotten passwords, etc.) and heavily impacts the IT department's budget.
Between the security requirements, performance and ergonomy, the eSSO solution proposed by
Ilex enables:
 Automating password reset operations
 Improving employee productivity
 Reducing operational costs
 Increasing the security of your systems
The security policies that you implement in order to protect your applications do not generally
depend upon the type of client in use (ex: Webmail or thick client). So why use 2 different tools,
duplicate effort (implementation, maintenance, interoperability…) and multiply the associated
risks?
Sign&go is a new generation SSO solution which unites Web SSO, Identity Federation and eSSO
by centralising the definition of security policies and audit information.
Sign&go provides simple and coherent user interfaces and rapidly adapts to your environment
and its constraints whilst respecting standards.

Sign&go
Sign&go protects the company's various applications without the need for deployment on each
user workstation.
Composed of security servers and agents which can be installed on the various Web and
Reverse-Proxy servers available on the market, Sign&go intercepts all communications and
applies the security policies and SSO strategies defined by the company's IT department.
Its modular architecture supports very high loads in addition to the most demanding high
availability constraints.
Extranet type architecture:

Sign&go
4. Functionality of Sign&go
In this section:
 Authentication (page 15)
 Authorisation (page 16)
 Single Sign-On (page 16)
 Auditing access to company resources (page 18)
4.1 Authentication
Sign&go is based on a powerful and adaptable authentication engine. This open engine integrates
numerous authentication methods as standard, from routine to the highest security:
 Identifier/password
 One Time Password (RSA SecurID, Vasco, etc.)
 Radius
 X509 certificates (files, smart cards, USB keys, biometric)
 CPS card
 CPS card + Vitale card
 Contactless (RFID) cards/password
 Xiring CPS smart card reader
 NTLM
 Kerberos
 Checkpoint OPSEC
 Custom (APIs, SMS messages, specific shemes)
 SAML v1 and v2
 OAuth v2 (Facebook, Google mail, Windows Live)
 Encrypted cookie (Pelican)
Sign&go is capable of retrieving and exploiting the password strategies defined within databases
and directories (Active Directory, SunONE …). It reinforces traditional authentications both by
imposing stronger password policies and by permitting account locking in the case of failed
authentication.
In the case of the company's repository not incorporating strategy functions, Sign&go provides its
own, thus guaranteeing increased security in all cases.
Highly flexible, the security engine enables the application of authentication schemes according
to the criticality of the application accessed. It is also possible to deploy several authentication
methods concurrently and to impose on the user the requirement to reauthenticate when wanting
to access a more sensitive resource.

Sign&go
4.2 Authorisation
In this section:
 Access control (page 16)
 Centralised access protection (page 16)
4.2.1 Access control

The rules engine integrated to the Sign&go security servers permits the implementation of
elaborate security policies. These security policies can contain combinations of topology tests (IP,
secured access, etc.), access periods, authentication levels or even user characteristics
(attributes, group membership, roles, etc.).
Adaptable, the rules engine is capable of dynamically referencing the company's data repositories
in order to evaluate security policies. In addition, Sign&go allows implementation of resource
access restrictions according to elaborate combinations of criteria.
Example: access to sensitive resources is only allowed to internal company employees
duly authenticated, possessing the role ''research & development'' and only during office
hours.
In order to manage more complex security policies, Sign&go provides administrators with a
powerful scripting language. This enables the implementation of an elaborate series of linked
tests.
4.2.2 Centralised access protection

Conceived for the tightest integration with applications and data repositories, Sign&go unifies the
control of access to the company's various resources.
Once implemented, Sign&go guarantees the implementation of your security policies, whichever
applications are targeted for access.
The administration console centralises the management of different security polices and thus
provides a summary of the views of access rights to the company's Information Systems.
4.3 Single Sign-On

In this section:
 SSO for mainframe, Client/Server and Web based applications (page 16)
 Identity Federation with partners (B2B) (page 17)
 Identity Federation with customers (B2C) (page 18)
4.3.1 SSO for mainframe, Client/Server and Web based

applications
Positioned upstream from the company's various IT applications, Sign&go guarantees the
centralisation of authentication functions and the application of security policies.
Having been assured that only authorised personnel have access to resources, freeing users from
authentication on different applications can be envisaged, resulting in increased productivity and
reduced Helpdesk requests.
Sign&go is a solution capable of executing unique signature strategies for your Web, mainframe
and Client/Server applications.

Sign&go
4.3.1.1 Web applications

Sign&go permits the application of numerous SSO strategies, thus assuring the propagation of
identity whichever application is protected.
Whenever it proves impossible to modify the application, Sign&go simulates the user
authentication (automatic completion of HTML forms, simulation of Basic HTTP authentication,
etc.). The credentials to be entered can be recovered from external sources or even memorised
on-the-fly by the product in an encrypted software container.
Sign&go SSO agents are available for the main application servers on the market (ISS, Apache,
SunONE, etc.). These SSO agents forge a trusted relationship between the security solution and
the targeted applications, thereby ensuring the propagation of identities whilst avoiding secondary
authentications.
Sign&go is capable of transmitting diverse information regarding the user to the applications
(identity, roles, authentication method, etc.). This information can be directly transmitted by the
HTTP channel (headers, cookie values, form parameters, etc.) which guarantees applications an
elegant security solution integration without resorting to an API.
4.3.1.2 Mainframe applications

Ilex's strong expertise in the market for terminal emulations, reinforced by the success of its
connectivity product Intranex, has allowed it to launch a security solution for mainframe
applications.
To this end, the Telnet SSO gateway applies the SSO strategies and the defined IT security
policies unintrusively on the workstations or mainframes.
4.3.1.3 Client/Server applications

The IT applications suite is not limited to Web applications, therefore Sign&go has an SSO
component, the eSSO Bridge destined for traditional Client/Server applications at its disposal.
The eSSO Bridge, integrated within the browsers, carries out the execution of SSO on the Client/
Server applications using Web-only scenarios and HTTP-only flows. Therefore, the user can
benefit from SSO, without experiencing any service disruption, via a portal giving access to local
and internally managed applications or to applications in SaaS mode, published in a public,
private or hybrid cloud.
Simple to use, with no prior deployment whatsoever, the eSSO Bridge permits the integration of
Client/Server applications into the company's Web portals.
4.3.2 Identity Federation with partners (B2B)

To confront the problems of eBusiness, the company must open up its information systems to the
outside world. Identity Federation (provision of information regarding the identity of a user
between several partner sites) respond to this need whilst ensuring the propagation of the identity
between the company and its partners.
The technological architecture retained by the different protagonists is of little importance. From
the moment that they are compatible with standard protocols, they will be able to propagate the
identities of the connected users between the different platforms.
Identity Federation brings an improved integration between partner sites in an eBusiness context.
Such is the case, for example, in an automatic transfer of a customer to a partner site during the
process of purchasing a service associated with an offering (plane ticket + car hire, etc.) or inter-
company communication.
In addition, Identity Federation opens the way to a simplification of the interconnection of different
services between large companies. In fact, these protocols permit different security solutions to
interoperate.

Sign&go
Finally, equipped with native identity management protocols like SAML, Sign&go is a security
product guaranteeing the company a lasting investment interoperable with other solutions on the
market.
4.3.3 Identity Federation with customers (B2C)

Recently, the OAuth2 protocol has become the standard for most leading Web companies such
as Facebook, Live ID, DailyMotion, Google or Twitter. Sign&go is one of the few IAM solutions to
have integrated ''OAuth2'' authentication, thereby maintaining a significant advance in Identity
Federation.
By retrieving the authentication performed on an OAuth2 compatible site, Sign&go allows a Web
user (who has on average a dozen digital accounts (*), to authenticate only once and to benefit
from their first authentication to access other sites.
Over and above its ease of use, the solution addresses key business issues. By enhancing
navigation, it helps improve customer loyalty by increasing stickiness. Without the constraints of
repeated registration and authentication, users can easily access online services.
4.4 Auditing access to company resources

The capacity of a security product to capture the history of authentications and access attempts
is essential. In fact, to legally guarantee access traceability, it is imperative that the access
journals are centralised and secured. This centralised journaling functionality permits the supply
of proof of the use of IT resources after the fact.
Sign&go assures the archiving of all authentication and authorisation events on the Information
System. These elements, consultable and easily consolidated with the analysis console, are
recorded in a database. They can be exploited directly by analysis tools from Business
Intelligence or from the Sign&go administration tool based on Jasper Report, in order to
consolidate personalised audit reports.
Built on an open model, the journaling engine is capable of propagating the events under different
forms, according to type and criticality (files, databases, SNMP traps, email, etc.).

Sign&go
Chapter 2
Architecture types
In this chapter:
 Overview of Sign&go (page 21)
 Securing external access (page 23)
 Securing internal access (page 27)
Ilex 19
Sign&go
20 Architecture types Ilex

Sign&go
1. Overview of Sign&go
In this section:
 Principle of Sign&go (page 21)
 Components of Sign&go (page 21)
 Schema (page 22)
1.1 Principle of Sign&go

Sign&go, the Single Sign-On (SSO) tool, puts in place a mechanism whereby the user needs to
authenticate only once in order to access several heterogeneous resources.
In fact, Sign&go memorises the identity of the user in an encrypted session cookie at the first
authentication (primary authentication). This session cookie is stored in the user's browser in the
form of a memory resident cookie. All subsequent authentications of the user (secondary
authentications) will then be stored by Sign&go thanks to this cookie.
The phases of user authentication and authorisation are controlled by the Sign&go security
server.
1.2 Components of Sign&go

Sign&go makes use of a configuration directory (or database) which enables its various
components to interact:
Sign&go component Description
Security server Intervenes during the user authentication and

authorisation phases and constitutes the essential
element of Sign&go (equipped with an "intelligence").
Authentication and Perform the role of intermediary between the user

authorisation agents workstation and the security server during authentication
and authorisation.
Administration server Permits the centralised management of Sign&go

(configuration).
User directories Reference all users of the information system.
To ensure the user authentication and authorisation phases, the security server
relies on the configuration and user directories.
Ilex Architecture types 21

Sign&go
1.3 Schema
The general architecture of Sign&go is shown in the following diagram:

Sign&go
2. Securing external access
In this section:
 Simple configuration (page 23)
 High availability configuration (page 25)
2.1 Simple configuration

The Web Reverse-Proxy SSO architecture is highly recommended whenever you need to secure
external access, in other words to resolve Extranet type issues.
Sign&go does not impose the use of reverse-proxy. It is perfectly possible to protect external
access by Sign&go agents installed directly on the Web servers.
2.1.1 Principle
The Web Reverse-Proxy SSO architecture is based on a module placed between the user and
the Web application server: the Web Reverse-Proxy. This module accepts the requests and
routes the information to the destination applications.
The Sign&go agent installed in the Reverse-Proxy carries out the SSO process. Indeed, it
validates the authorisations and can alter the Web application requests in order to simulate a client
authentication (secondary authentication).
2.1.2 Schema
The following schema illustrates a Web Reverse-Proxy SSO architecture:

Sign&go
2.1.3 Operation
Here the user has only one intermediary: the Reverse-Proxy. Therefore it is necessary to modify
the company's DNS configuration such that the Reverse-Proxy is seen as the destination server.
In this way, the user authenticates against the Reverse-Proxy with the help of standard
authentication methods. This server then authorises or denies access to the final URLs by using
the resource protection methods of the security server.
The Sign&go agents are installed directly onto the Web Reverse-Proxies positioned at the entry
to the network. These agents solicit all the security servers, using load-balancing algorithms for
example, and thus retrieve the strategies to be applied.
2.1.4 Advantages
The main advantages of the Web Reverse-Proxy SSO architecture are based on:
 Installation: the security Reverse-Proxy sits in the connection chain between the client
and the servers. Therefore no modification whatsoever is required to the servers or the
clients (non-intrusive to the targeted system).
 Architecture: the operations are carried out at the HTTP protocol level, which is why this
system of SSO remains independent of the physical architecture (OS, hardware).
Furthermore, this system masks the network topology. In fact, the security portal is the
only machine accessible by the client; this permits the creation of a demilitarised zone
(DMZ), an area equipped with intermediate security between the exterior and interior of
the company. One sole Reverse-Proxy is therefore capable of protecting all the Web
servers.
2.1.5 Restrictions
The Web Reverse-Proxy SSO architecture presents certain limits:
 The need to reinforce security: due to the interruption of the connection chain between
the client and the Intranet server, security must be reinforced by making sure that the
destination servers are placed as close as possible to the Reverse-Proxy. This is a large
constraint in an Intranet environment.
 The loading (high availability): the portal is the obligatory point of passage to the
applications. As a consequence, issues of Reverse-Proxy loading can arise. Therefore,
in order to conserve the global level of high availability, it is urged that the same resilient
architecture is put in place on the Reverse-Proxy as on the Web server.
 The SSL: this system of SSO supports partial compatibility with SSL. When the user
authenticates by certificate to the Web Reverse-Proxy, the Web Reverse-Proxy cannot
then make use of the user's certificate to authenticate to the server.
In this case, the user information is transmitted in the form of application information
(HTTP headers) between the Reverse-Proxy and the server. In fact, the authentication by
certificates intrinsically necessitates direct communication, without interruption in the
chain.

Sign&go
2.2 High availability configuration

The modular architecture of Sign&go facilitates its implementation into high availability
configurations.
2.2.1 Combinations of security servers

Each Sign&go agent is capable of connecting to all servers according to two modes:
 Round-robin: the agent connects successively to each security server in order to
balance the load between different servers.
 Fail-over: if the interrogated server does not respond, the agent will try the next one.
2.2.2 Independence of security servers

The Sign&go architecture, based on the notion of a secured session token, makes the security
servers independent from each other.
A person could authenticate against a first agent/security server pair, then present their session
token to a second agent/security server pair: the security servers would have no need to
communicate together. In fact, the security servers share a secret that serves as the basis for the
calculation of the encryption keys of the session tokens. They therefore use the same session
token encryption keys and constitute a zone of confidence (interoperable servers).
2.2.3 Loading
A complex multi-level cache mechanism exists between the agents and the security servers. This
cache rapidly makes an agent autonomous with regard to a given user.
The cache mechanisms of Sign&go optimise the performance in a radical fashion and thereby
permit the graceful handling of load increases.

Sign&go

Sign&go
3. Securing internal access
In this section:
 Web Proxy SSO architecture (page 27)
 Filter based Web SSO architecture (page 29)
 Multi-site architecture (page 31)
 Identity Federation (page 32)
3.1 Web Proxy SSO architecture

The Web Proxy SSO architecture is highly recommended whenever you need to secure internal
access, in other words to resolve Intranet type issues.
3.1.1 Principle
This architecture implies the modification of the client browser configurations in order to direct
connections to a Proxy. The Proxy intercepts the requests and routes the information to the
destination applications.
The Proxy carries out the SSO process. However it does not satisfy itself with simply routing the
client request to the correct machine, but alters the requests in order to simulate an authentication
of the client to the Web application (secondary authentication).
3.1.2 Schema
The following schema illustrates a Web Proxy SSO architecture:
3.1.3 Operation
After configuration of the user's browser, all requests systematically pass via the Proxy, even if
the client wishes to reach a Web site exterior to the company.
Once the user is authenticated, the Proxy authorises or denies access to the destination URLs.

Sign&go
3.1.4 Advantages
The main advantages of the Web Proxy SSO architecture are based on:
 Installation: after the configuration of the client workstations, the HTTP protocol directly
manages the connections passing through the Proxy. There is no need to modify the
sever DNS configurations (as is the case for Reverse-Proxy). This system is therefore
non-intrusive on the servers.
 Architecture: all operations are conducted at the level of the HTTP protocol, therefore
this system of SSO remains independent of the underlying architecture. After the
configuration of the client workstations, all of the Web servers are potentially accessible.
 Load balancing (high availability): in order to take account of the constraints of high
availability, several proxies can be configured at the user workstation level.
3.1.5 Restrictions
The Web Proxy SSO architecture presents certain limits:
 The need to reinforce security: due to the interruption of the connection chain between
the client and the Web server, security must be reinforced by making sure that the
destination servers are placed as close as possible to the Proxy. This is a large
constraint in an Intranet environment.
When SSO is implemented, the HTTPS protocol in Proxy mode imposes upon the Proxy
the decryption of the data flow before any connection to the destination server. The Proxy
is therefore installed as a "man-in-the-middle proxy". As such, for security it constitutes a
strategic entry point, and so should be reinforced by securing the Operating Systems and
installing firewalls for example.
 The configuration: this system imposes modification of the configuration of the user
workstations. Therefore, you cannot install it on user workstations remote from the IT
infrastructure or, more generally, where there is no control over the user workstation.
 The SSL: this system of SSO supports partial compatibility with SSL. When the user
authenticates by certificate to the Web Proxy, the Web Proxy cannot then make use of
the user's certificate to authenticate to the server. In fact, the authentication by
certificates intrinsically necessitates direct communication, without interruption in the
chain.

Sign&go
3.2 Filter based Web SSO architecture

The filter based Web SSO architecture is highly recommended when you need to resolve
problems of decentralised Intranet connections, in other words whenever the target servers are
spread around the company or, once again, when the security constraint is very high.
3.2.1 Principle
This architecture consists of:
 A security server: taking charge of the management of users.
 Filters (agents): deployed on each server hosting the applications to be protected.
These filters provide upstream protection for the different applications. They are tasked
with obtaining authentication information from the server.
3.2.2 Schema
The following schema illustrates a filter based Web SSO architecture:
The Sign&go security servers are centralised. The various Sign&go agents are installed on the
company's Web servers, which can be geographically distributed over several sites, as well as
Reverse-Proxies.
3.2.3 Operation
The user looks to access a portal site. After verification of the authentication on the portal, the
security server returns the user's access rights on the site in question back to the agent. An
authentication token is stored on the user's workstation. This token is subsequently recovered at
each client connection to a server and permits the verification of its authentication.
If the user tries to access another site, the agent for this site will consult the security server. The
user having already been authenticated (authentication token), the agent directly returns the
user's rights on the new site.

Sign&go
3.2.4 Advantages
The main advantages of the filter based Web SSO architecture are based upon:
 Security: the security of the data flow is assured from end to end.
 Load balancing (high availability): the load is naturally distributed between the
different servers and can be managed more easily due to the absence of bottlenecks.
 SSL: no intermediary exists between the browser and the Web server, resulting in the
possibility of strong authentication from end to end (PKI and X509 certificates).
3.2.5 Restrictions
The filter based Web SSO architecture presents certain limits:
 Installation: you must install a filtering agent on each Web server to be protected
(intrusive on the target system).
 Filters specific to the servers to be protected: this SSO system is dependent upon
architecture because specific filters are required for the platforms and Web servers.
Sign&go provides the following filters:
Platforms Web servers and proxies
Windows  Microsoft IIS 4, 5 and 6

 Microsoft ISA Server 2000, 2003, 2004 and 2006
 Microsoft Forefront TMG 2010
 Apache 1.3.x
 Apache 2.0.x
 Apache 2.2.x
 Lotus Domino Application Server versions 6.0 and 6.5
 Netscape
 iPlanet
 Sun One Web Server
 Sun One Proxy Server
 ICAP compatible Agent
 Ilex Proxy
Linux  Apache 1.3.x

 Apache 2.0.x
 Apache 2.2.x
 Ilex Proxy
Z/Linux  Apache 1.3

 Apache 2.0

Sign&go
Platforms Web servers and proxies
Solaris  Netscape
 iPlanet
 Sun One Web Server
 Sun One Proxy Server 3.x
 Sun One Proxy Server 4.x
 ICAP compatible Agent
 Ilex Proxy
 Apache 2.2
AIX  Lotus Domino Application Server 6.0 and 6.5

 IBM HTTP Server based on Apache 1.3 and 2.0
 Apache 1.3, 2.0 and 2.2
3.3 Multi-site architecture

The Sign&go security servers are installed on the various production sites, as close as possible
to the Web servers to be protected. The Sign&go agents are installed on the Web and Reverse-
Proxy servers. By priority these agents communicate with the local security servers first.
The security servers are configured in such a way that they all form part of the same zone of
confidence. A user duly authenticated by one security server will be authenticated by another
without the need to communicate between them.
Schema:

Sign&go
3.4 Identity Federation

In the case of business partners, the required resources can be distributed across different sites.
Sign&go allows each of the partners to access and share these resources by means of Identity
Federation (SAML protocol and identity propagation).
Example: the coupled train ticket + hotel offering of two companies will be based on a
Sign&go architecture with Identity Federation.

Sign&go
Chapter 3
Configuration
In this chapter:
 Authorisation (page 41)
 SSO strategies (page 47)
 Secondary credentials (page 51)
Ilex 33
Sign&go
34 Configuration Ilex
Sign&go
1. Authentication
In this section:
 Concepts (page 35)
 Walk-through of an authentication (page 39)
 Case example (page 40)
1.1 Concepts
In this section:
 Principles of authentication (page 35)
 Using existing directories (page 36)
 Authentication policies (page 36)
 Authentication agents (page 37)
 Authentication schemes (page 37)
 Session token (page 38)
1.1.1 Principles of authentication

1.1.1.1 Primary authentication
Primary authentication consists in identifying the user, ensuring they are who they claim to be by
verifying some information that comes from this user. A successful authentication results in the
creation of a Sign&go "token" which represents this user.
The authentication operation corresponds to two distinct and complementary functions:
 The identification, which associates an identifier to the entity connecting to the
system: this function is assured by the security server.
 The authentication, which verifies and confirms that the entity is indeed who it
claims to be: this function is assured by the authentication schemes linked to the
company's directories; schemes and directories are configured in the security server.
After primary authentication and validation, a session token is generated by the security server. It
serves the role of a user passport for SSO and accessing resources.
1.1.1.2 Secondary authentication

Secondary authentication consists in identifying the user in a transparent manner by simulating
their authentication to Web applications.
SSO permits simulating the entry of secondary authentications. The user can thus access an
application without having to provide the credentials (called "secondary") expected by this
application.
The secondary identifiers and passwords of the users, called "secondary credentials", are
encrypted and stored according to preference in:
 The company's user directories (LDAP or SQL), keeping in mind that an extension of
the scheme is necessary.
 An SQL database, whereby the scheme is provided by Sign&go.
Ilex Configuration 35
Sign&go
1.1.2 Using existing directories

In this section:
 Primary directory (page 36)
 Other existing directories (page 36)
 Personalisation (page 36)
1.1.2.1 Primary directory

All the user's authentication data is stored in the company's directories. Sign&go functions with all
LDAP directories, and therefore Active Directory, as well as all SQL databases compatible with
JDBC.
We name the company directory that contains the work profiles the "primary directory". This
directory can be chosen as the reference directory for Sign&go. If this is the case, the primary
directory is consulted at each new authentication, when a user referenced in another directory
tries to connect, Sign&go makes use of directory mappings for the authentication.
The choice of a primary directory is not mandatory. Sign&go can function with several directories
at the same level without expressly passing via the primary directory.
1.1.2.2 Other existing directories

Several of the company's directories can be configured in order to define the location of users,
groups, and work profiles.
Subsequently, the Sign&go connectors are capable of directly exploiting the authorisations of the
users contained in these directories. This information is conveyed dynamically to the different
Sign&go components (authentication schemes, criteria, etc.).
1.1.2.3 Personalisation
Personalised mappings and connections of directories can be created. The mapping of directories
permits locating a user in a targeted directory when they are known in the source directory. This
is the case, for example, of a company possessing a primary (reference) and several dedicated
directories (internal personnel, external personnel, etc.).
1.1.3 Authentication policies

The process of authentication of a user is started when they try to access a resource but do not
possess a token permitting this access.
The authentication policies are then executed in order to determine how the user should be
authenticated, and possibly by which authentication agent, according to the context of the user
authentication.
Examples: domain, client IP address, time period, etc.
Sign&go
1.1.4 Authentication agents

The role of an authentication agent is to carry out the primary authentication of the user and to
generate a token if it is successful.
Several authentication agents can be necessary at the same time, for example for different
authentication schemes or in order to distribute load with the same scheme.
In accordance with the way in which an authentication agent retrieves the credentials, we
distinguish two categories of authentication agents:
 API authentication agents: these agents interact with the user to request proof of their
identity (identifier/password, CPS card, etc.).
Installed on the Web servers, these agents have specific URLs and are only active when
a request is destined explicitly for them. In virtually all cases, this happens when a user
looks to access a protected resource: the authorisation agent which intercepted the
request then effects a redirection to the URL of the authentication agent API. If the
authentication is successful, the authentication agent installs the session token as a
cookie in the browser and redirects to the URL initially requested by the user.
 WEB authentication agents: these silent agents retrieve the credentials (primary)
without intervention by the user. They are integrated into the authorisation agents that
intercept the user's requests and are implicitly activated at the time of processing the
user request.
Authentication by a WEB agent is always implicit. No possibility exists to redirect the user
to a WEB agent in order to authenticate.
1.1.5 Authentication schemes

A Sign&go authentication scheme permits the specification of the type of authentication that is
going to be used during the primary user authentication phase.
One or several authentication schemes can be associated with an authentication agent via an
intermediate authentication list.
This way, whenever a user looks to access a resource, the security server sequentially executes
the authentication schemes associated with the authentication agent until one of them succeeds.
These authentication schemes verify the identity of the user against the associated directories. If
the authentication is validated, the security server generates a session token which is sent to the
authentication agent.
An authentication scheme is configured with a confidence level. This confidence level is referred
to in the identity of the session token.
It is possible to extend the Sign&go authentication schemes by creating one's own. These
personalised schemes are administered in the same way as the standard Sign&go schemes.
An authentication list groups authentication schemes in an ordered manner. Each
authentication agent is associated with an authentication list.
The personalised authentication schemes automatically appear in the list of authentication
schemes in order to create a personal authentication list.
Sign&go
1.1.6 Session token

A session token is a unique piece of information that carries proof of the user's identity. When an
authentication is successful, it is generated by the security server then positioned on the user's
workstation in the form of a memory resident cookie by the authentication agent.
This session token serves as the user's passport by conveying their identity. In order to guarantee
its integrity, the information that it contains is signed and encrypted.
Stored in the user workstation’s browser, the session token has an absolute lifetime. This period,
defined by the administrator, is an integral part of the session token.
The initial session token manages the user's secondary authentications for as long as it is valid.
The validity of the session token for access to a resource depends upon its absolute lifetime and
domain of validity.
When the token remains inactive for a length of time, the "timestamp" permits the
definition of an "inactivity timeout" which overrides the absolute lifetime of the
token.
A session token is composed of several encrypted blocks:
The identity of the session token is defined at the time of its creation and contains the following
elements:
 User identity
 Directory in which the user was identified
 Authentication agent
 Time and date of authentication
 Confidence level of the means of authentication
 Absolute lifetime of the token
 Unique serial number of the token
The user profile and authorisations can be refined, throughout the lifetime of the token, with
optional information (identifier, secondary password, work profile, etc.). This application
information, limited to 2KB, is delivered directly to the authorisation agents at the time of
authentication.
Sign&go
1.2 Walk-through of an authentication

The authentication of a user occurs in the following manner:
1. The user attempts to access a resource protected by Sign&go.
2. The authorisation agent intercepts the request and solicits the security server.
3. The security server executes the authentication policy.
4. The authorisation agent redirects the user to the authentication URL, which can be:
 A Web server (identifier/password, OTP, etc.)
 A Web URL (Basic HTTP, X509, etc.)
5. The authentication server presents the available authentication schemes to the user. The
user chooses one of them (identifier/password, OTP, Basic HTTP, X509 certificate, etc.).
6. The authentication agent sends the user's credentials to the Web server, then to the
security server.
7. The user's credentials are validated against the directory, the session token is then
generated.
8. The session token is installed and the user is redirected to the original resource.
Sign&go
1.3 Case example

The authentication of a health professional on a local health authority's network using Sign&go
santé operates in the following manner:
1. The health professional connects to the Internet via his usual Internet Service Provider.
He starts his browser and enters the URL of the local health authority's network.
2. Sign&go Santé detects that the health professional is not authenticated. It asks him to
insert his CPS card in order to perform the authentication phase.
3. The health professional inserts his CPS card in the usual card reader.
4. The authentication component detects the insertion of the card, retrieves the public data
and displays an image of the CPS card. It requests that the health professional enters his
PIN code in order to authenticate.
5. After verifying the accuracy of the information displayed on the screen, the health
professional enters his PIN code in the authentication component of Sign&go santé and
clicks the OK button in order to start the authentication phase.
6. Sign&go santé makes use of the cryptographic capabilities of the CPS card to
authenticate the health professional. The authentication relies on the X509 certificate
stored in the CPS card. During the authentication phase the Sign&go santé security server
consults the GIP-CPS revocation list of the ASIP Santé (ex GIP-CPS) situated in the GIP
LDAP directory.
7. Once the health professional is correctly authenticated, the Sign&go protection agent
validates the authorisations of the professional and gives him access to the Web server of
the local health authority's network. Furthermore, the protection agent provides the local
health authority application with the professional's identity in order to carry out an SSO
operation on the site.
The health professional has access to the local health authority application until he
closes his browser or removes his CPS card from the reader.
Sign&go
2. Authorisation
In this section:
 Walk-through of access to a protected resource (page 43)
2.1 Concepts
In this section:
 Principle of authorisation (page 41)
 Access rules (page 42)
 Criteria (page 42)
 Behaviours (page 43)
2.1.1 Principle of authorisation

All objects that a user attempts to access (Web page, directory, JSP page, CGI script, servlet, etc.)
correspond to a resource.
An authorisation policy permits a given agent (Web Filters, Proxy/Reverse-Proxy) to protect a
set of resources. The authorisation policy permits or denies access to the resources requested by
the user, according to the access rules of which it is composed.
The confidence level of the authorisation policy corresponds to that which is required for access
to the resources protected by this policy. If the individual's current confidence level (determined
during authentication and contained in the session token) is inferior to the level required, the
access rules are applied as if the user did not possess a session token.
The confidence level associated with an authentication is defined in the

authentication schemes.
When a user tries to access a protected resource, the security server attempts to authenticate
them using the information collected by the authorisation agent that intercepted the request.
Whatever the results of the authentication, the authorisation management phase is then started.
The security server searches for the authorisation policy associated with the resource. If the
authorisation phase is successful, the user is authorised to access the requested resource.
When a resource is associated with several security policies, the security server
applies the authorisation policy with the highest priority and most restrictive in
regards to the resource.
Sign&go
2.1.2 Access rules

When a user requests access to a resource, an access rule determines the behaviour to be
followed.
An access rule is used by authorisation policies. When several rules are used by the same
access rule, they are executed sequentially.
An access rule associated with an authorisation zone can be used by all authorisation policies
in the zone.
An access rule enables both:
 Performing tests on the circumstances of the user access (time period, user profile,
authentication level, etc.): these tests correspond to Sign&go criteria.
 Managing the SSO strategies: these strategies correspond to Sign&go behaviour and
are applied according to success or failure of the tests.
An access rule is composed of 3 elements:

 Criteria
 Behaviours to execute if the rule succeeds: behaviour OK
 Behaviours to execute if the rule fails: behaviour KO
For a rule to succeed, all of the criteria of which it is composed of must evaluate successfully. The
failure of any one of the criteria will result in the rule not succeeding.
A rule can explicitly terminate execution of the security rules. This allows, for
example, the creation of an access control rule common to all security policies,
which stops execution of other access rules if the user is not authenticated.
2.1.3 Criteria
By default, in order to execute certain criteria (group, work profiles, etc.), the security server
connects to the company's primary directory. Criteria are the fundamental tests executed on the
user's request, and can consist of, for example:
 The presence or absence of a session token
 The level of authentication specified in the session token
 The validation of the user's IP address
 The user's work profiles
 The user group
 The user's attributes
 The current date and time, etc.
Once configured, the criteria are automatically displayed in the criteria list of the corresponding
access rule.
It is possible to extend the Sign&go criteria by creating one's own. These personalised criteria
appear in the criteria list and are administered in the same way as the standard Sign&go criteria.
Sign&go
2.1.4 Behaviours
At the end of the authorisation phase, the security server sends the behaviours to the agent.
A behaviour indicates an action to be taken on the request. Depending on its type, it is executed
either by the security server (for example, in the case of adding application data to the token), or
by the agent (for example, when adding HTTP headers to the request). If the access rule is valid,
the OK behaviours are executed, otherwise the KO behaviours are.
We distinguish three types of behaviours:

 Access control (authorisation or refusal of access to the resource, redirection of a user
to another URL)
 SSO (Basic HTTP authentication simulation, auto completion of HTML forms)
 Passing information to the Web application (insertion of new URL parameters or
HTTP headers)
The behaviours can restart the authentication process if a high enough confidence level to use
certain resources is not achieved the first time around.
It is possible to extend the list of Sign&go behaviours by creating one's own. These personalised
behaviours are administered in the same way as the standard Sign&go behaviours.
2.2 Walk-through of access to a protected resource

When a user attempts to access a resource protected by Sign&go, an agent intercepts the request
and solicits the security server. The authorisation management phase operates in the following
manner:
1. The security server looks up the most restrictive authorisation policy associated with the
resource.
2. The security server sequentially executes the access rules attached to this authorisation
policy.
3. An access rule succeeds when all of the constituent criteria are validated. Otherwise the
access rule fails.
4. The session token and behaviours are sent to the agent in response to the criteria tests
of the access rules.
5. The agent applies all of the behaviours that it receives.
6. The user receives the response to their request. If the authorisation phase is successful
then the session token is placed in the user's browser in the form of a memory resident
cookie.
A cache mechanism avoids the necessity of making a new request at each

access attempt by the same user.
If the authorisation agent possesses an authentication list then the authentication

phase is carried out before authorisation. Whatever the result, the authorisation
phase is then carried out.
Sign&go
2.3 Case example

In this section:
 Access to a protected resource by means of a Web filter (page 44)
 Access to a protected resource by means of a Proxy/Reverse-Proxy (page 45)
 Explanation of access to a resource protected by means of a Web filter or Proxy/
Reverse-Proxy (page 45)
2.3.1 Access to a protected resource by means of a Web

filter
The following schema illustrates access to a resource protected by a Sign&go Web filter agent:
Sign&go
2.3.2 Access to a protected resource by means of a Proxy/

Reverse-Proxy
The following schema illustrates access to a resource protected by a Sign&go Proxy/Reverse-
Proxy agent:
2.3.3 Explanation of access to a resource protected by

means of a Web filter or Proxy/Reverse-Proxy
Authorisation of the user by a Sign&go Web filter or a Sign&go Proxy/Reverse-proxy operates in
the following manner:
1. A user, previously authenticated, looks to access a resource protected by the Web server.
2. The agent installed on the server intercepts the user's request and solicits the security
server. The security server provides the agent with the user's session token (generated
during a previous authentication), the requested resource, as well as information linked to
the context (IP address of the user's workstation, etc.).
3. The security server retrieves the authorisation policy associated with the resource.
4. The security server sequentially executes the access rules attached to the authorisation
policy of the resource. An access rule consists of all the criteria to test and the behaviours
corresponding to the actions which the agent must perform.
5. The security server sends the agent all the behaviours (authorisation and SSO) as well as
the session token.
6. The agent applies all of the behaviours.
7. The user receives the response to their request. The session token is stored as a memory
resident cookie in the workstation's browser.
In the case where several authorisation policies are eligible for a given resource,
Sign&go chooses the most restrictive corresponding to the resource.
Sign&go
Sign&go
3. SSO strategies
In this section:
 Walk-through of an SSO strategy (page 47)
 Implementation (page 48)
3.1 Concepts
Sign&go centralises all of the authentication functions. It permits the application of numerous SSO
strategies that assure the propagation of the identity whichever application is protected (Web,
mainframe and client/server).
When a user is already authenticated on the company's information systems, Sign&go is capable
of simulating their secondary authentication to an application, in other words to avoid
authentication operations relative to this resource by applying one of the following SSO strategies:
 The propagation of information (the recovery and passing of values)
 The automatic learning of application identifiers/passwords (Basic HTTP)
 The automatic completion of HTML forms
To do this, Sign&go retrieves the credentials to be inserted in the login dialogue box or HTML form
for example, from external sources or memorised on-the-fly in an encrypted software container.
Sign&go is also capable of transmitting diverse information concerning the user (identity, roles,
authentication method, etc.) directly to the applications by the HTTP channel, in the form of
headers, cookie values, form parameters, etc.
3.2 Walk-through of an SSO strategy

An SSO strategy operates in the following manner:
1. The user looks to access a resource protected by the Web server. He clicks on an
application link in the portal.
2. An authorisation agent installed on the server intercepts the request and provides the
security server with the installed session token for this user (generated during the primary
authentication).
3. The security server retrieves the user's credentials, with the help of information provided
by the session token, and transmits them to the agent.
4. The agent dynamically transmits the credentials necessary for the user's secondary
authentication to the protected resource.
5. The user accesses the protected resource in a transparent manner.
In order to transmit the secondary credentials to the protected resource, the

security server proceeds in one of the following ways:
 It enters the user's login/password in a login dialogue box.
 It automatically completes the fields of an HTML form.
 It propagates the personal information in the form of HTTP headers, etc.
Sign&go
3.3 Implementation
In order to access protected resources, the administrator would like to configure an SSO strategy
allowing to retrieve the user's credentials.
To do this, he creates a new authorisation policy in the Sign&go administration interface for the
resource concerned.
The administrator associates an access rule to this authorisation policy defining how to proceed
when a user requests to access the resources.
Sign&go
This access rule contains:

 A criteria of type "Check the existence of secondary credentials", in other words the
basic tests to carry out on the user's request.
 The OK behaviours, to be executed if the rule succeeds (for example, the automatic
completion of login dialogue boxes or HTML forms, etc.).
 The KO behaviours, to be executed if the rule fails (for example, the redirection to an
error page, displaying of an error message, etc.).
Sign&go
Sign&go
4. Secondary credentials
In this section:
 Walk-through of credentials management (page 51)
 Credentials management interface (page 53)
4.1 Concepts
The management of secondary credentials, called self-registering, uses the client APIs of Sign&
go. It consists in:
1. Saving the authentication data (an identifier/password pair)
2. Performing updates
3. Performing deletions
4.2 Walk-through of credentials management

Secondary credentials are managed in the following way:
1. The administrator first indicates the desired directory and attribute to be used to store the
user's authentication data.
2. When the user attempts to access a protected resource on the Web server, an
authorisation agent provides the security server with the user's session token.
3. The security server retrieves the user's credentials by following the access rules
associated with the activated security policy.
This access rule can, for example, be a test of type "Validity of a session token" or "Check
the existence of secondary credentials".
4. According to the success or failure of the access rule, the security server dynamically
applies the appropriate behaviours.
For example, it can:
 Authorise the user's access when the validity of the token is verified.
 When the existence of the secondary credentials are verified, load them into the
session, complete the SSO identification in Basic HTTP then authorise the user's
access, etc.
5. The user accesses the protected resource in a transparent manner.
Sign&go
4.3 Implementation
The management of secondary credentials requires pre-selecting the data storage directory,
whether it is of type LDAP or SQL, in the Sign&go administration interface.
Next, the attribute of the directory which will be used for storing the secondary credentials should
be defined.
Once the directory and attribute have been entered, the administrator creates the authorisation
policy that will be applied when a user attempts to access a protected resource.
This authorisation policy integrates an access rule which will load the secondary credentials and
transmit them to the protected resource or, alternatively, redirect them to the user registration
page.
Sign&go
Here are two examples of access rules, which show how they can be associated with the
authorisation policy:
 "Token Verification"
This access rule verifies whether the token exists, in other words whether the user has
already been authenticated.
 If this rule succeeds and the token exists, then the OK behaviour "Access granted" is
applied.
 If this rule fails because the token does not exist, then the following KO behaviours
"Redirection towards a URL" and "Access granted" are executed.
 "SSO management"
This access rule loads the secondary authentication parameters and integrates them into
HTTP headers in order to conform to the Basic HTTP format.
 If this rule succeeds and the credentials are found, then the following OK behaviours
are applied:
"Loading into the session of the secondary credentials"
"SSO identification in Basic HTTP or other behaviour"
"Access granted"
 If this rule fails because the credentials cannot be found, then the following KO
behaviours are executed:
"Redirection towards the secondary authentication URL"
"Access granted"
4.4 Credentials management interface

By default, Sign&go includes a secondary credentials management page. It enables the user to
update and/or delete their secondary credentials.
This page only displays applications for which the user's secondary credentials have already been
entered into the directory.
It is equally possible to create a specific JSP page adapted to the company.
Sign&go
Sign&go
Chapter 4
Advanced concepts
In this chapter:
 Auditing (page 57)
 Directory mapping (page 61)
 Multi-domain (page 63)
 SAML (page 67)
 Scripts (page 73)
Ilex 55
Sign&go
56 Advanced concepts Ilex

Sign&go
1. Auditing
In this section:
 Overview (page 57)
 Configuration (page 58)
 Case examples (page 58)
1.1 Overview
Sign&go is equipped with a journaling engine which logs all of the authentication and authorisation
events. This engine, integrated into the security server, enables the consolidation of auditing
information in the form of text files or database entries.
An independent Sign&go application, once configured, permits the display of auditing information
in a readable manner. This application is accessible from the Sign&go administration interface.
1.2 Concepts
Auditing is characterised by the recording of information linked to the surveillance of a process on
some form of support. In regard to the Sign&go security server, the processes surveyed are the
phases of user authentication and authorisation.
In respect to the security server, the audit information corresponds to that saved during a user's
successful or unsuccessful authentication or authorisation.
Certain types of information can be common to several processes and other types specific only to
one.
Information specific to authentication operations answer the following questions:

 Who has tried to authenticate?
 By which means?
 At what time?
 What was the result?
Information specific to authorisation operations answer the following questions:

 Who has tried to access a resource?
 Which resource was the object of an attempted access?
 By which means?
 What was the result?
Whether it is an authentication or authorisation, the principal information is the log date, the time
and its reference. This last element corresponds to a numerical value between:
 1 and 999 in the case of a successful authentication
 1001 and 1999 in the case of a successful authorisation
 5001 and 49999 in the case of an unsuccessful authentication
 500001 and 99999 in the case of an unsuccessful authorisation
Ilex Advanced concepts 57

Sign&go
1.3 Configuration
The Sign&go journaling engine is built upon the Open Source Log4j library.
By default, the audit information of the Sign&go security server is saved in text files
(sngauthentication and sngauthorization) in extended W3C format, but can equally be saved
directly to a database.
In addition, according to the method used, the audit information can be saved on any given
support. Modification of the configuration file server.xml, situated in the security server's
installation directory, is all that is required in order to do this.
Finally, wherever the company already possesses an audit log consolidation product, it is perfectly
possible to import the logs into a spreadsheet generating tool.
There is an item of information to note, which links the authentication and

authorisation logs: the serial number of the token. It is therefore possible to
correlate the logs in order to follow the path of the user from their first
authentication through their various authorisations.
1.4 Case examples

By default, Sign&go is delivered with a pre-configured database, comprising columns named
according to the type of audit information returned.
1.4.1 Information available in the authentication logs
 Date (ms)  Authentication  Schemes used  Authentication

state persistence
indicator
 Client IP address  Token content  Scheme level  New token content
 Agent name  Token level  Scheme directory  New token serial n°

list
 Main directory  Token TTL  Initial user ID  New token level
 Log type  Token initial user  Authentication  New token TTL

ID directory
 Log message  Token user ID  Directory mapping  New token initial

user ID
 Scheme name  Client TCP port  User ID  New token user ID
 Token serial n°  Agent TCP port  Scheme type 
 Processing time  Scheme list  Scheme 

description

Sign&go
1.4.2 Information available in the authorisation logs
 Date (ms)  Protected resource  Token level  Policy trust level
 Client IP address  Behaviours applied  Token TTL  Response TTL
 Agent name  Policy name  Token initial user  Rules applied

ID
 Log message  Token serial n°  Token user ID  Secure link
 Log type  Processing time  Client TCP port  HTTP headers
 Zone name  Token content  Agent TCP port  Resource list
 Requested   
resource
 To personalise the audit logs, and in particular, the authentication and authorisation
parameters returned, in the log manager's homepage, click the Configuration menu.
The log files configuration page is displayed. This page enables to define:
 The type of database
 The JDBC driver
 The JDBC connection URL
 The identifier/password
 The number of lines displayed per page
 The start and end dates of the logs to be displayed

Sign&go

Sign&go
2. Directory mapping
Several directories can co-exist and be used in parallel throughout a company, according to the
work profiles of the employees. It is possible, for example to work with:
 A directory of internal company employees and another for external service providers
 A directory created for and used by the IT department, and another dedicated to and
used by administrative staff, etc.
In this context, it is necessary to resolve the question of authentication of company employees

who are listed in both directories.
Sign&go responds to this issue of multiple directories by means of directory mapping. Directory
mapping ensures conformity between attributes of the primary directory (defined in the Sign&go
administration interface) and those of one or several annex directories. In other words, in the case
of a user A entered in the primary directory B and also in another directory C, it is possible to
retrieve user A from directory C.
Directory mapping provides the advantage of not having to modify anything within existing
applications. As such, any company is able to install and use Sign&go without first having to
merge their existing directories into a single one, a task which requires both time and resources.

Sign&go

Sign&go
3. Multi-domain
In this section:
 Overview (page 63)
 Walk-through (page 65)
3.1 Overview
SSO security solutions rely on cookie mechanisms in order to maintain user sessions. These
cookies are generally associated with a DNS domain.
In the case where a company has several root DNS domains, due to the propagation limit of the
cookies between the domains, the implementation of an SSO solution can turn out to be tedious.
Sign&go takes charge of this constraint and directly manages the SSO in the company, including
where several DNS domains are present. This functionality, called Cross Domain SSO, is outlined
below.
3.2 Concepts
In this section:
 Domain (page 63)
 Principal domain (page 63)
 Authentication domain (page 64)
 Single domain SSO (page 64)
 Multi-domain SSO (page 64)
 Target domains (page 64)
3.2.1 Domain
The word domain is a general concept used in a Web context, in other words in an environment
which consists of a group of Web servers hosting resources accessible by their respective URLs.
A domain corresponds to all of the resources and associated servers in which the DNS name is
terminated by the same suffix. The domain is designated by this suffix which is composed of
several components separated by dots (".").
Since it has a tree structure, a domain can contain other domains called "sub-domains".
3.2.2 Principal domain

In Sign&go, a principal domain designates a domain situated at the top of the company's
network architecture hierarchy and which contains at least one server equipped with a Sign&go
agent. In other words, a principal domain contains sub-domains and at least one addressable
machine.

Sign&go
3.2.3 Authentication domain

In Sign&go, an authentication domain contains one or more authentication agents. It is on this
domain that the cookie containing the Sign&go token is placed at the time of its creation.
Example:
The authentication domain acme.com contains the authentication agent having the URL
www.acme.com/auth/dologin.jsp. The generated Sign&go cookie will be valid
throughout the acme.com domain (for example: portal.acme.com, intranet.acme.com).
Several authentication agents can exist simultaneously, on one or more machines, within the
same domain in order to respond to the following issues:
 Implementation of different authorisation schemes
 Distribution of the authentication load across several machines
3.2.4 Single domain SSO

In the majority of cases, the company's information system consists of only one domain. In this
type of architecture, called single domain, the authentication domain constitutes the company's
principal domain. All that is required therefore, is the creation of the token on the principal domain
for it to be accessible to all of the sub-domains.
3.2.5 Multi-domain SSO

Multi-domain SSO is applied in the case where the network architecture contains separate
domains.
Functionally, multi-domain SSO consists in authenticating the user and only then allowing them
access to URLs which are situated within all the domains, notably domains that have no
relationship with the authentication domain.
Technically, multi-domain SSO consists in propagating the user's authentication (the Sign&go
token) from the authentication domain to the domains or sub-domains which are not part of the
authentication domain.
Multi-domain SSO applies only to Sign&go architectures that have the same
security context and enables a simple solution to the technical constraints of SSO
on several DNS domains within a single company. Propagation of the
authentication to another security infrastructure is done using SAML technology
(for example: authentication propagation to or from a partner or an outsourced
application).
3.2.6 Target domains

The domains and sub-domains, other than the authentication domain, managed by multi-domain
SSO are called target domains. Target domains correspond to the domains to which the user
authentication is propagated.
Therefore, multi-domain SSO consists in exporting the Sign&go token from the authentication
domain to the target domains.
In regards to multi-domain SSO, the administrator has two possibilities:

 Restrict the propagation of the user's authentication to specific
domains, by configuration
 Authorise the propagation of the user's authentication to all target
domains accessed by the user (default configuration)

Sign&go
3.3 Walk-through
Multi-domain SSO is implemented with the help of Sign&go authentication agents and the
following functional entities:
 An export agent situated in the authentication domain and charged with exporting the
Sign&go token.
As such, the export agent and all the authentication agents are to be found within the
authentication domain in which all the Sign&go tokens are created.
 Import agents situated within each target domain and charged with importing the
Sign&go token to the target domain concerned.
Communication between the export and the import agents is essentially carried out by the
browser, using the redirection mechanism. However, sensitive data is relayed via the security
server.
These two entities are integrated into the Sign&go Web agent and require no specific installation.
On the other hand, it is necessary to configure beforehand some information concerning each of
them, via the Sign&go administration interface.
Example: Authentication on a principal domain, then access to a resource on a target
domain.
The user is already authenticated on domain A. They attempt to access a resource

situated on domain B, requiring a level compatible with their previous authentication:
 Step 1: the user makes a request without a token for accessing a resource on
domain B.
 Step 2: the Sign&go Import agent intercepts their request and redirects it to the
Sign&go Export agent.
 Step 3: the Sign&go Export agent retrieves the user's token (issued at the time
of authentication on domain A) and transmits it to the security server along with
their authentication level.
 Step 4: the security server verifies against the configuration directory, that the
token provides a sufficient level. It conserves a copy of the token and returns an
Artifact to the Sign&go Export agent.

Sign&go
 Steps 5 and 6: the Sign&go Export agent retrieves the Artifact and redirects the
user to domain B’s Sign&go Import agent.
 Steps 7 and 8: the Sign&go Import agent extracts the Artifact from the request,
provides it to the security server, retrieves the token, installs it and performs a
redirection to the URL initially requested by the user. The browser remakes the
original request, but this time with a token.
3.4 Case example

A company possesses several DNS domains for external access. It hosts several sites because
it possesses several brands such as www.ilex.fr, www.meibo.com, www.signandgo.com, etc. As
such, for example, the user can access www.meibo.com and www.signandgo.com from the site
www.ilex.fr without having to reauthenticate.
For more information on cookie specifications, refer to the following URLs:

 http://curl.haxx.se/rfc/cookie_spec.html
 http://www.faqs.org/rfcs/rfc2965.html

Sign&go
4. SAML
In this section:
 Usage context (page 68)
 Walk-through (page 69)
4.1 Concepts
4.1.1 Definition
SAML (Security Assertion Markup Language) is a standard protocol for the propagation of user
identity information.
Standardised by the OASIS SSTC (XML-based Security Services Technical Committee), SAML
is built on the XML language in order to respond to issues of user identity propagation between
third-party platforms.
SAML guarantees the security of exchanges by assuring the authentication of the parties and the
integrity of the exchanged data. In order to do this, it relies on a secure communications protocol
such as HTTPS, or it integrates the management of XML signatures by X509 certificates.
SAML formalises the format of requests and responses in the form of XML documents, and
equally the transmission mode of these documents. It therefore permits the propagation of data
concerning the identity, attributes and rights of a user.
The SAML standard enables the exchange of user identity information by the use of HTTP and
SOAP protocols. These protocols, Internet standards, offer the advantage of being compatible
with the constraints of company security (firewalls, etc.).
4.1.2 Issues
SAML answers the eBusiness issues of today, by assuring the propagation of identities between
the company's information system and its partners.
From the moment that each of the partner's architectures is compatible with SAML, it is possible
to propagate the user's identities connected to the different platforms.
As such, SAML facilitates the interconnection between different partner sites just like those of
individual departments within a large company, because it permits different security solutions to
interoperate.

Sign&go
4.2 Usage context
4.2.1 Extranet
In an Extranet context, the company can need to exchange user identity information with its
partners.
The partners generally possess their own security architecture. It is not normally possible or
desirable to impose the installation of specific components or the Sign&go solution on the partner
in order to make the management of identities compatible.
The SAML protocol responds to this issue by permitting, with no prior installation on the partner's
systems:
 The provision of the identity of a user connected to the partner
 The automatic retrieval of a user's identity provided by the partner
4.2.2 Intranet
In an Intranet context, the implementation of the SAML protocol permits different subsidiary
companies to manage the security of their information systems whilst at the same time
establishing trusted connections between them.
As such, each subsidiary or entity can conserve the management of their own users whilst
remaining open to the rest of the company, by the intermediate SAML identity propagation.
4.3 Implementation
The Sign&go administration interface enables the configuration of the SAML partners who will be
exchanging user identities.
Once configured, Sign&go is capable of providing and retrieving identities. In fact, the Sign&go
security servers have been based on XML which is compatible with SAML. Also, the SAML
authentication schemes permit, for each partner, the definition of the conditions under which the
user's identity is propagated.
In terms of architecture, Sign&go supports both HTTP and HTTPS. In order to do this, a "Sign&go
SAML" Web application is deployed. This Java application, compatible with J2EE servers
available on the market (Tomcat, Websphere, etc.), is in permanent contact with the security
servers and in this way plays the role of the Sign&go SAML agent.
The valuable principle of task separation recommended by Kerberos is maintained by Sign&go.
The Sign&go SAML agent thus plays the role of "Policy Enforcement Point", whilst the security
servers continue to assume the role of "Policy Decision Point". This type of architecture,
distinguishing the functions of decision taking and the application of a decision, guarantees
increased security from the moment of the solutions' implementation.

Sign&go
4.4 Walk-through
SAML permits the propagation of the person's identity and free attributes between different sites,
in accordance with standard protocols. In fact, whichever technical architectures the participants
concerned have employed, provided that they are compatible with these protocols, they will be
able to propagate their user's identities between the different platforms.
As such, SAML is very often used in the framework of Web services destined for public use, such
as coupled offers for train ticket + hotel reservation, etc. In the same way, in the context of an inter-
company issue, SAML is frequently used for propagating user's identities to an external ASP
(Application Service Provider) platform hosting all of the company's services. Such as in the case
of a company with an outsourced applications suite accessible from an ASP.
The following example illustrates the propagation of a user identity from a Sign&go secured
platform to an SAML compatible partner.
It presents a Sign&go use case in "IdP Initiated" SAML mode, similar to the operation mode
prevailing in SAML version 1.1. With this mode, it is up to the IdP to propagate the identity.
Other architecture models, such as the "SP Initiated" mode are possible. For
more information, refer to the Sign&go SAMLV2 Operation Guide.

Sign&go
POST profile ARTIFACT profile
Common walk-through - POST and ARTIFACT profiles:
 Step 1:
The user accesses the identity provider (or "IdP") portal for the first time.
 Steps 2 and 3:
The Sign&go agent intercepts the request and solicits the security server to perform the local
authentication phase on the IdP.
As the user is not already authenticated, an authentication page is returned.
 Steps 4, 5 and 6:
The user successfully authenticates. A Sign&go token is created and installed on the user's
workstation. This allows the user to access the portal.
 Steps 7, 8 and 9:
This is actually the beginning of the SAML operations with the transfer of the authentication obtained
on the IdP to the partner's "service provider".
The user attempts to access a partner site via a link on the portal.
The user is then redirected to the application server, hosting the IdP's Sign&go SAML Web
application.
 Step 10:
This Sign&go SAML Web application, equipped with a Sign&go API agent, interrogates the security
server in order to retrieve all of the information necessary for the creation of a SAML assertion.
Distinct walk-through - POST or ARTIFACT profiles:
 Step 11:  Step 11:

The signed SAML assertion An "artifact" (short message representing the SAML assertion) is
is returned to the browser as returned to the IdP by the browser as a form which is automatically
a form which the browser submitted to the service provider (SP).
automatically submits to the
service provider (SP).
 Step 12:  Step 12:

This SAML assertion is sent The artifact received by the partner's service provider (SP) can be
to the partner site, which "exchanged" with the IdP to obtain an assertion.
validates the message's
signature and decrypts its
contents with the help of the
SAML connector.
 Step 13:  Step 13:

The user accesses the It is the artifact resolution phase.
requested resource via an
With the artifact, the partner's service provider (SP) requests the
HTTP redirection.
resolution of this artifact from the IdP on a direct, secured
connection with the IdP (SSL with client authentication).

Sign&go
POST profile ARTIFACT profile
 Step 14:
The "SAML responder" on the IdP site responds via an assertion to
the artifact resolution request submitted by the service provider
(SP).
The assertion is used by the service provider (SP) and converted in
local authentication of the user on the service provider's site.
 Step 15:
The user accesses the requested resource via an HTTP redirection.

Sign&go
4.5 Case example

The following schema illustrates the implementation of SAML. This installation requires no
modification of the architecture.
The propagation of the user's identity between partner sites can be carried out by a partner site
or indeed to a partner site:
 Provision of the user's identity by a partner site:
In order to propagate the identity of the user to a platform, the partner must send an SAML
response with an assertion, solicited or not by an authentication request, to a URL specific
to the Sign&go Web authentication server.
This URL uses the Sign&go SAML agent in order to validate, on the security server, the
validity of the transmitted information (partner identity, integrity of the message, identity
and rights of the proposed user, etc.).
The security server then generates a Sign&go session token. This token, guaranteeing the
identity of the user, is then installed on the client workstation in the form of a session
cookie in order to serve as proof of identity during subsequent access to the local platform.
 Propagation of a user's identity to a partner site:
In order to automatically provide a partner site with the user identity, you need to create
links to a URL specific to the Sign&go Web authentication server.
This URL takes charge of the redirection of the user and the propagation of their identity
("POST Profile" or "Artifact Profile") to the partner site.
The partner site is then able to retrieve the user's attributes or information regarding their
rights by soliciting Sign&go via its intermediate Web authentication server.

Sign&go
5. Scripts
In this section:
 Case examples (page 74)
 Examples (page 75)
5.1 Concepts
Integrated to the security server, and with the assistance of its APIs, the script engine offers
numerous possibilities for personalisation. Notably, it brings:
 An optimal flexibility of the product, in order to be able to respond to specific, atypical or
complex cases.
 The ability to solicit external repositories.
 An advanced personalisation, without the need to resort to complex development
environments (such as Java, C, etc.)
The creation of a script is carried out within the administration console. It is then directly saved in
the Sign&go configuration. Modifications are taken into account in real time by the security server.
The script engine can be used in:

 Authentication schemes
 Rules criteria
 Rules behaviours
 Variables
 Directory mapping
Compatible with the syntax of the JavaScript 1.0 scripting language, the script engine possesses
a high performance integrated environment thanks to the security server's editor/debugger.
This editor enables:
 More intuitive writing of scripts than with the administration console
 Step by step execution
 Saving of scripts directly within the Sign&go configuration
The editor requires a graphical environment such as Windows, X11, etc. It runs on the security
server and interrupts the transactions in progress. Therefore it is not advisable to run it on
production platforms.
Finally, specific objects enable interaction with the security servers. It is possible, for example, to
instantiate and control external Java classes.

Sign&go
5.2 Case examples

The scripts all possess an object, already instantiated, which allows them to retrieve the current
context (request, user token, etc.) and, alternatively, to install a status or a response.
5.2.1 Authentication
Authentication scripts are associated with authentication schemes. Executed once an
authentication has succeeded, they allow to:
 Distinguish the Sign&go token by using information originating from the authentication,
directories, etc.
 Interrupt the authentication phase based on external criteria.
 Carry out personalised tasks (updating the directory, etc.).
5.2.2 Criteria
Criteria scripts are associated with specific rule criteria. They allow to:
 Carry out authorisation tests according to topological elements, period, group
membership, authentication level, etc.
 Consolidate session information destined for other behaviours or criteria.
5.2.3 Behaviour
Behaviour scripts are associated with specific behaviour or group of behaviours. They allow to:
 Carry out an access control.
 Control agents in order to modify requests (add headers, cookies, etc.).
 Consolidate session information destined for other behaviours.
5.2.4 Variable
Variable scripts enable factoring in specific processing. Called from other scripts by simple
evaluation of the variable, they allow to:
 Collect information from an external source or by using a particular algorithm.
It is possible to pass parameters to variable scripts by the use of session methods

of the Request object.

Sign&go
5.2.5 Directory mapping

Directory mapping scripts are associated to a mapping of directories, they allow to:
 Find the user in a target directory, when they are known in the source directory.
5.3 Examples
In this section:
 Criteria (page 76)
 Behaviour (page 76)
 Variable (page 77)
 Directory mapping (page 77)
5.3.1 Authentication
The following authentication script performs the modification of a user's LDAP attribute:
var request = authenticationschema.getRequest();

var token = authenticationschema.getToken();
var GUID = token.getGUID();

var userDN = GUID.getUserID();
var directory = GUID.getDirectory();
var connection = directory.getConnection();

try {
var attrs = new javax.naming.directory.BasicAttributes();
attrs.put("telephoneNumber", token.getAuthenticationSchemaName());
connection.modifyAttributes(userDN, connection.REPLACE_ATTRIBUTE,
attrs);
}
catch(exception) {
scripter.print(exception.toString());
}
if(connection != null)
directory.releaseConnection(connection);

Sign&go
5.3.2 Criteria
The following criteria script authorises access to the information system according to the user's IP
address:
var request = criteria.getRequest();

var checker = new ilex.signandgo.server.pub.criteria.IPChecker();
checker.addIPRange(“192.168.0.1/24”);
var ip = request.getClientIP();
if(checker.checkIP(ip))
criteria.setSucceed();
else
criteria.setFailed();
5.3.3 Behaviour
The following behaviour script enables the retrieval of secondary credentials and the passing to
Basic HTTP:
var request = behavior.getRequest();

var response = behavior.getResponse();
var token = request.getToken();
if(token == null)
exit();
var credentials =
token.getCredentials(request.getContextValue(“POLICY.APPLICATIONNAME”));
If(credentials != null) {
var login = credentials.getProperty(“LOGIN”);
var password = credentials. getProperty(“PASSWORD”);
response.setBasicHttpSSO(login, password);
response.setAccessGranted();
}

Sign&go
5.3.4 Variable
The following variable script sends a new URL (round-robin) at each evaluation of the variable:
var context = variable.getContext();

var request = context.getRequest();
var saltcounter = request.getApplicationValue("SALTCOUNTER");

if(saltcounter == null) {
saltcounter = "0";
}
var urls = new Array(2);
urls[0] = "http://security1.acme.com/auth/chooseschema.jsp";
urls[1] = "http://security2.acme.com/auth/chooseschema.jsp";
var ival = parseInt(saltcounter);

ival = ival+1;
ival = ival%urls.length;
saltcounter = ""+ival;
request.addApplicationValue("SALTCOUNTER", saltcounter);
variable.setValue(urls[ival]);
5.3.5 Directory mapping

The following directory mapping script performs the mapping of a user according to the value of
an attribute in the destination directory:
var guid = directorymapping.getGUID();

var login = guid.getUserLogin();
var dest = directorymapping.getDestinationDirectory();
var uid = dest.getUserIDByAttribute(“altLogin”, login);
If(uid != null) {
directorymapping.setMappedUserID(dest.makeGUID(uid));
}

Sign&go

Sign&go Architecture Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sign&go Architecture Guide

Uploaded by

Copyright:

Available Formats

Architectures &

Copyright Ilex 2015. All rights reserved.

II. ARCHITECTURE TYPES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

III. CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

IV. ADVANCED CONCEPTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

8 Overview of Sign&go Ilex

1.1 Securing access to information systems

1.2 Sign&go, access control and secure SSO

1.3 Sign&go, first ''Global SSO'' solution

Ilex Overview of Sign&go 9

10 Overview of Sign&go Ilex

2. When should Sign&go be used?

Ilex Overview of Sign&go 11

12 Overview of Sign&go Ilex

Ilex Overview of Sign&go 13

14 Overview of Sign&go Ilex

Ilex Overview of Sign&go 15

4.2.1 Access control

4.2.2 Centralised access protection

4.3 Single Sign-On

4.3.1 SSO for mainframe, Client/Server and Web based

16 Overview of Sign&go Ilex

4.3.1.1 Web applications

4.3.1.2 Mainframe applications

4.3.1.3 Client/Server applications

4.3.2 Identity Federation with partners (B2B)

Ilex Overview of Sign&go 17

4.3.3 Identity Federation with customers (B2C)

4.4 Auditing access to company resources

18 Overview of Sign&go Ilex

20 Architecture types Ilex

1.1 Principle of Sign&go

1.2 Components of Sign&go

Sign&go component Description

Security server Intervenes during the user authentication and

Authentication and Perform the role of intermediary between the user

Administration server Permits the centralised management of Sign&go

User directories Reference all users of the information system.

Ilex Architecture types 21

22 Architecture types Ilex

2. Securing external access

2.1 Simple configuration

Ilex Architecture types 23

24 Architecture types Ilex

2.2 High availability configuration

2.2.1 Combinations of security servers

2.2.2 Independence of security servers

Ilex Architecture types 25

26 Architecture types Ilex

3. Securing internal access

3.1 Web Proxy SSO architecture

Ilex Architecture types 27

28 Architecture types Ilex

3.2 Filter based Web SSO architecture

Ilex Architecture types 29

Platforms Web servers and proxies

Windows  Microsoft IIS 4, 5 and 6

Linux  Apache 1.3.x

Z/Linux  Apache 1.3

30 Architecture types Ilex

Platforms Web servers and proxies

AIX  Lotus Domino Application Server 6.0 and 6.5

3.3 Multi-site architecture