Authentication and Authorization Protocols

for Primefaces Applications and Environments

Nazri Abdullah1,2, Ioannis Kounelis1, Sead Muftic1
1
Network Systems Laboratory
School of Information and Communication Technology
KTH Royal Institute of Technology, Stockholm, Sweden
{nazri,kounelis,sead}@kth.se
2
Universiti Tun Hussein Onn Malaysia, Johor, Malaysia
anazri@uthm.edu.my

Abstract: In this paper we describe our design and current implementation of the authentication and
authorization protocols for Primefaces applications and environments. Starting with the standard
concept of those two protocols, we introduce innovative solutions supporting all four assurance levels
of authentication and role-based authorization protocol. We also describe the architecture of
Primefaces components needed as support for our protocols as security extensions of Primefaces
applications. We have very efficient and operational implementation of both protocols described in the
last section of this paper. The components of our two protocols are generic and fully functional, so that
developers can easily integrate them into their applications.
Keywords: Authentication, Authorization, Single Sign-On (SSO), Access Control, Java Server Faces (JSF),
Primefaces.

Introduction

Single sign-on (SSO) is a version of user authentication protocol that allows users to authenticate explicitly only
once and subsequently use an authentication credential (SSO Ticket) in order to be repetitively transparently
authenticated by multiple applications distributed in a single or even in multiple domains. This approach eliminates
the problem of repetitive multiple registrations of user identities and their separate verification by different
applications in a distributed environment. SSO protocol ensures protection, usability and consistency of both users
and applications security profiles and credentials. It improves network security by protecting security credentials and
SSO Tickets that can be securely transmitted and used by all applications. Most of current implementations are based
on centralized identity management system under centralized infrastructure and with distributed Relying Parties (RP)
[1]. Our concept and current implementation support fully distributed and federated environments.
Authorization is an approach to control and allow access to system resources and applications only to authorized
users. Common approach used today is rolebased access control RBAC [2][3]. RBAC has been specified as an
international standard that controls access to computer resources and application data based on user roles, access rules,
permissions, and policies. Roles and permissions are assigned to users and then used to specify rules that control their
access to system resources and privileges to use these resources. RBAC has several important features: it supports the
principle of least privileges which has been considered very important for better security of systems; users access
privileges and permissions can be easily changed when his/her role is changed within the organization by removing
the current role and assigning him/her a new role. Decisions to access and use resources are made by the RBAC system
transparently and in realtime [4].
Primefaces [5] is the concept, the framework for development, the set of operational modules, and a methodology
for building Web applications. Applications are based on standardized specifications of User Interfaces (UI) supported
by server-side modules, called JavaServer Faces (JSF). Before the concept of JSF was introduced, developers of Web
applications built user interface components using primarily HTML technology, called JavaServer Pages (JSP).
However, JSF technology is more powerful than HTML. JSF modules are detached from backend processing

modules, they run on servers, and render User Interfaces back to clients. This concept improves productivity and
consistency of Web applications by reuse of standardized and readily available components.
In recent years Primefaces became popular Web applications development and deployment framework, as it offers
rich functionality, flexibility, and rapid prototyping development. Its greatest advantage is separation between
functional modules (called beans) and modules used for presentation of components, functions, and data to users (UI
modules: forms, dialogs and xhtml pages). JSP technology could not map HTTP requests to component-specific
eventhandling modules, nor could it manage UI elements as stateful objects at the server side, as JSF. Furthermore,
JSF also allows developers to build Web applications that implement finer-grained separation of functionality and
presentation, what traditionally has been supported by client-side UI technologies (Javascripts). The most important
property of the JSF concept is that it provides a rich architecture for managing component states, used for efficient
processing of data, for validation of users inputs, and for handling exceptional events.
Based on all these features and properties, Primefaces is more and more used for development of complex Web
applications, both for standard websites and also for business Web servers. It provides to developers samples of code
for each of the UI components and functions, which may be easily included in their applications. However, standard
Primefaces concept and available modules do not include any aspect of security. This means that developers must
create their own such components and features and then integrate them with the Java Spring Security. Primefaces
system is lacking security and control modules, what represents the main motive and goal of our research and
development activities, and the main contribution of this paper.
In this paper we describe our design and implementation of a new approach to the authentication and authorization
protocols targeting primarily Web applications developed and deployed using Primefaces technology. With our
concept, Primefaces components of different applications are accessed, activated and used based on a single login
process. During that process user authentication ticket is created and kept by the Identity or Authentication Server as
long as user remains active and online. The ticket is reusable for authenticating to multiple applications in the network.
In addition, the ticket is used to determine authorization of the user to access various Primefaces functional modules
and UI components based on users role. Our innovative approach is in fact design and development and methodology
for incorporation of all three, authentication, single signon, and authorization protocols in Primefaces applications in
the form of readymade, generic, and pluggable modules. Our implementation also includes components of the
security infrastructure needed to support these three protocols, like Identity Provider, Authentication Provider, and
Authorization Provider, together with all required security messages exchanged between all components of our secure
environment.
This paper is organized as follows: in Section 2 we give brief introduction of related research and development
results. In Section 3 we describe the design of our SSO protocol for the Primefaces environments. In Section 4 we
demonstrate the implementation and use of the protocol. And in Section 5 we close this paper with conclusions.

Current Technologies and Standards

At the time of this research, there are three possibilities to implement security features, such as authentication and
authorization, for Primefaces applications. The first is using Java EE container for managing user authentication [6].
With this approach application developers specify security constraints by defining access privileges to a collection of
resources using URL mapping. Security constraints includes three sub-elements: Web Resource Collection a list of
URLs targeting resources that need to be protected; Authorization Constraint specifies whether authentication should
be enforced and also roles that are authorized to perform the constrained request; and User Data Constraint specifies
protection of data during transfer between a client and a server. Although use of this approach is easy and its setup is
simple, it has several serious disadvantages. The configuration is specific for each container, there is no fine-grained
control, error handling is very poor, and there are no restrictions based on permissions.
The second possibility is to create proprietary servlet filter, which can perform fine-grained control, but every
developer must implement it individually. This approach requires very advanced skills, as the developer must know
how to implement servlet filter without any weaknesses and potential security holes. Such filter may be completely

independent of the specific container, but this activity means re-building the same components as described in the first
option. If some specific features of the filter are required, a lot of code is needed, what makes the filter vulnerable to
conceptual, design, and implementation errors.
The last option for implementation of authentication and authorization protocols for Primefaces is by using some
thirdparty framework, such as Apache Shiro [7] or Spring Security [8]. There are some advantages of using such
frameworks as developers do not need to write any code and the approach offers more options to specify fine-grained
configurations and authorization restrictions than standard containermanaged authentication. Existing frameworks
are already mature, since those are professional products, tested by many developers, users and enterprises, what
makes them quite stable and robust. However, these two specific frameworks require substantial effort by developers
in order to learn how to integrate them with their Primefaces applications.
When it comes to standards, the most commonly used standard for the SSO protocol is Security Assertion Markup
Language (SAML). SAML is an XML system that allows domains to exchange user authentication and authorization
data [9]. Multiple Web applications and service providers can use different online Identity Providers to authenticate
users who want to access and use sensitive data handled by these applications. The other two popular standards are
OpenID [10] and Open Authorization (OAuth) [11]. SAML and OpenID are standards for authentication and OAuth
specifies authorization mechanisms and protocols.
SAML 2.0 is the standard based on XML and used for exchanging authentication and authorization credentials
between different security domains. It supports W3C XML encryption and signature security services in order to
satisfy user privacy and data integrity requirements. There are three parties participating in the protocol and one of
them is a user who is being authenticated. The other two perform authentication: the first party, acting as asserting
party (usually called Identity Services Provider) is a component authorized to register, provide and authenticate user
identifiers and authentication attributes, while the second party, playing the role of a relying party (usually called
Application Services Provider), uses authentication services provided by the first party. Application Services Provider
must trust the asserting party when issuing authorization to a user to use its application services. The subject of this
protocol is identity of the user involved in a transaction. The protocol for exchange of assertions between these three
parties is based on request and response messages.
There are several protocols specified in the SAML 2.0 standard. However, the most important is Authentication
Request Protocol. The process of user authentication starts at the Application Services Provider when user accesses
its services selection page. The Provider, before allowing user to access and use requested services, redirects user
request and issues an explicit authentication request to the Identity Provider. The HTTP Redirect Binding and the
HTTP POST Binding are commonly used for implementation of the Webbased SSO. For example, Application
Services Provider uses HTTP Redirect mechanism to send a request, while the Identity Services Provider uses HTTP
POST to return the response.
Another standard / version of the Web SSO protocol is OpenID, which is based on an open-source project with a
community driven standardization process. It does not abstract the details of its basic specification, but rather describes
a direct solution to the Web SSO problem. OpenID supports a decentralized architecture, which uses features of the
existing Domain Name Server (DNS) service. Anyone with the domain name can choose to be an OpenID Identity
Services Provider. Users who do not have their domain can register with the Identity Services Provider which they
trust. OpenID protocol effectively "piggybacks" on the DNS to solve IP discovery problem in combination with Web
SSO. In the authentication protocol, users are assigned identifiers based on a domain name. For example, user Alice
has OpenID identity alice@id-service.com registered at her trusted Identity Provider at www.id-service.com. When
she tries to access a protected resource at an Application Provider www.bob-blog.com, she supplies her OpenID
identity alice@id-service.com. Applications Provider at www.bob-blog.com contacts Identity Provider at www.idservice.com to authenticate Alice. To associate multiple OpenID identifiers to a single domain, OpenID uses the Yadis
protocol [12].
Figure 1 illustrates how OpenID authentication protocol works. As shown, Step 1: when a user connects to a
Relying Party (RP), the RP sets a Session ID for user and the user enters his/her OpenID identity into a field on the
RPs website. Step 2: The RP then uses users OpenID identity to discover the OpenID Identity Provider (IP)

information, such as address using the Yadis protocol, and Step 3: redirects the user to the IP. Step 4: When user
connects to the IP, the IP sets the Session ID for the user and the user enters his/her credentials into the IPs website
page. Step 5: If the credentials are verified, the IP creates secure Session ID for the user and returns authentication
token to the RP. Step 6: Then, the OP redirects the user to the RPs web page accessible by the authenticated user.

Fig. 1. OpenID model for achieving Web SSO

Design of Security Infrastructure for Primefaces Applications

3.1 Security Components and Extensions

Our main design goals for the two described protocols are: (a) to follow authentication and authorization standards,
and (b) to integrate them with Primefaces components. Our motives are based on the fact that current components and
modules in Primefaces environment do not include security, privacy or any control elements. Therefore, a broader
goal of our current research and development is to design and develop comprehensive set of security components,
which may be easily combined into an integrated, largescale, and functional security infrastructure based on
Primefaces. Currently we have designed and implemented, as the first version, only three such components: Security
Platform, based on our Java Generic Security APIs and OpenSSL cryptography, and two security protocols
Authentication and Authorization, both described in this paper.
We are planning our future security modules and extensions for Primefaces environments and applications to be
comprehensive and to include the following features and properties:

Security components and services already available:

- Initial authentication and Single Sign-on protocol
- Role-based access control system to control access to resources of any application
- Cryptographic functions for hashing, encryption, decryption and signing used as a Crypto Services
Provider

Components and security services for privacy and anonymity of users and their transactions:
- User identities and profiles will be encrypted and stored only within the server container and database.
- Usage of pseudonyms (public crypto keys) will be developed to hide real user identities.

Administration and management of security services:

- Rich Primefaces GUI components for administration and management of all security functions,
modular and therefore pluggable to any application, will be created using Primefaces technology
- Components will be packaged to export generic security interfaces, so they will be customizable and
pluggable to any application, in case of specific requirements

Extendibility of functionality:
- Components and methods are Java-based, so they may be easily expanded, replaced or customized
- Authentication protocols can be configured to support alternative assurance levels, including use of
smart cards at assurance level 4 [13]

Portability to different platforms:

- All designed security components and protocols can be used on any Java web-based platform.
- Protocols should easily migrate to mobile platforms, as Primefaces provides mobile UI Kit, which
may be used to create applications optimized for smartphones and other mobile devices.

3.2 Components for Primefaces Environment

This section describes the main components of the Primefaces architecture and how they function when combined and
integrated into a complete security infrastructure. Figure 2 shows the main components of the Servlet Container that
hosts Primefaces applications. The components of our security architecture, also hosted in the same Container, are the
following:
(a) Client: Users access application services using Web browsers. In our current design and implementation
of the Authentication and Authorization protocols, initial authentication is based on assurance level 1
(username and password) [13].
(b) View: Designer of Web applications can create Web UIs without any restrictions of their desired
presentation, as with Primefaces GUI modules are separated from application data and business logic.
(c) Controller: This is front-end Primefaces servlet that controls user interactions with the application by
guarding against unauthorized or improper access to application pages, functions, and resources.
(d) Model: This is a managed bean component (Java bean) that contains Getter and Setter methods,
business logic or even a back-end module (a bean that handles processing of HTML forms and Dialogs
values)
(e) Database: Storage of user and application data.
(f) Application Services/Modules: Modules providing applications services requested by a user.

Fig. 2. Architecture and its Components for Primefaces

3.3 Components of the Authentication and Authorization Protocols

There are six components involved in the process of authentication and authorization of users, shown in Figure 3.
(a) Primefaces UI components: Those are modules that render UI objects for request and response to users
and handle business logic (back-end bean).
(b) Navigation Controller: Performs page navigations and in that process verifies user authorization by
contacting Authorization Manager based on user role.
(c) Login/Logout Bean: Receives user credentials during authentication process, verifies them, and if correct
sends them to the Ticket Manager for issuing SSO ticket.
(d) SSO Authentication Module: Checks whether user session is still alive even if a user logs in from another
workstation in the network.
(e) Navigation Controller: Performs pages navigation and in that process verifies user authorization by
contacting Authorization Manager based on user role.
(f) Authorization Manager: This modules keeps user role during the entire session in order to control
navigation and access to the back-end beans and pages.
(g) Ticket Manager: Creates, updates and removes SSO tickets (user session profile).

Fig. 3. Authentication and Authorization Protocols Components

3.4 Authentication and Authorization Protocols Steps and Phases

Figure 4 shows authentication process initiated when a user accesses some security enhanced Primefaces Web
application. The process has four phases: (i) first, check whether the user already has SSO ticket, (ii) if not, create the
Ticket as the result of successful initial authentication, (iii) after valid Ticket is created / presented, perform control
of access to application resources based on user role and profile, and (iv) remove the Ticket from the session when
user logs out. The detail description of each of the steps is the following:
A. Initial step: Checking for valid SSO Ticket (Sequence A1 to A6)
The process starts by examining users profile by reading User-Agent HTTP header and IP address of
user workstation.
If the profile matches data in the existing Ticket, created earlier, then user may proceed to use the
application within the predetermined scope and role.
If the user does not have valid SSO Ticket, Web application starts in guest mode.
B. Initial authentication and creation of the Ticket (Sequence B1 to B7)
SSO Ticket is created after initial authentication is successfully completed. Client
registration/authentication profile is saved in the Ticket together with the starting date and time of the
session.

SSO Ticket remains valid until user logs out from the application / session.

C. Authorization decision (Sequence A4 to A5 and B5 to B6)

Authorization role of the logged user is read during authentication phase from the centralized
registration/authorization database.
User authorization profile / roles is provided by the Identity Management System (IDMS) where user
is registered.
Navigation of Web applications is controlled by the Navigation Controller, the module specified and
developed by the application(s) developer.
Control of access is not restricted only to one page, but control can be applied to any UI component,
such as buttons, tabs, dialogs and etc.
D. Ticket removal (Sequence C1 to C5)
This process is performed by cleaning the session from active beans and deleting SSO Ticket that was
saved in the database after its creation.
At the same time the system may reset page navigation to guest mode. This is performed when a user
logs out from the application.

Fig. 4. SSO Protocol for Primefaces Applications

4

Implementation

The described SSO authentication protocol for JSF-Primefaces applications and environments provides reasonable
aspects of security authentication with SSO with high usability and efficiency, as it is embedded in the hosting
application. In this section we briefly describe our current implementation of the SSO protocol combined with our
secure payment application based on virtual currencies Bitcoin. But the modules of the protocol can be embedded
in any other application.
In the first step, each user registers his/her contact data using the Dialog shown in Figure 5. It may be noticed that
First Name and Last Name are not required, so the system provides certain degree of anonymity. When accessing
various servers of the payment system and performing certain functions at each server, users must be authenticated.
Initial authentication, at the beginning of each session in the current version is based on login parameters, shown in
Figure 5 login name and password. As the result of successful initial authentication, single signon (SSO) Ticket is
issued and stored in database table encrypted with users password as encryption key.

In order to perform each of the payment operations (shown in Figure 6), user must be authenticated. However, if
the user has SSO Ticket, authentication will be performed automatically and for the user transparently using that
Ticket. If user performs authentication explicitly, by pushing Login button, the result will be reported by the success
message (shown in Figure 7).
However, after initial authentication and with the SSO Ticket issued, when selecting any of the payment system
functions (shown in Figure 6), authentication will be performed automatically and for user transparently in the
background, as part of the function initiation. If the user has valid Ticket, so that SSO authentication is successful, the
working Dialog of he selected payment function will be displayed.
Therefore, it is clear that our example application follows strictly authentication principles: each function can be
executed only by authenticated users and authentication is performed transparently and based on the single signon
protocol. User authenticates only once, at the beginning of the session, and thereafter, authentication is performed
implicitly, automatically and for the user transparently, before executing any of the protected system operations.

Fig. 5. Dialog for User Registration

Fig. 7. Explicit and SSO Login

Fig. 8. Open Account after Authentication

Fig. 6. Payment Functions

Conclusions

In the current version the described authentication protocol modules are integrated in our payment application for
virtual currencies. But, we are at the moment re-engineering them into a separate application which can, as the separate
WAR, be used by other applications without tight embedding of authentication modules with business logic modules
of the hosting application.
In the next phase, we will extend the described authentication protocol to support higher assurance levels, where
authentication at level 2 will be based on onetime password (OTP), at level 3 challenge/response protocol and
certificates will be used, and at level 4 we will extend our authentication protocol to use FIPS 201 (PIV) smart cards.

References

1
2

Relying party, Wikipedia, the free encyclopedia. 24-Aug-2014.

R. Cover, INCITS Announces ANSIs Approval of Role Based Access Control (RBAC) Security Standard.
[Online]. Available: http://xml.coverpages.org/ni2004-04-05-a.html#publications. [Accessed: 10-Oct-2014].
NIST.gov - Computer Security Division - Computer Security Resource Center. [Online]. Available:
http://csrc.nist.gov/groups/SNS/rbac/standards.html. [Accessed: 10-Oct-2014].
Y. Zhang and J. B. D. Joshi, Role Based Access Control, in Encyclopedia of Database Systems, L. LIU and
M. T. ZSU, Eds. Springer US, 2009, pp. 24472452.
Primefaces.Org, Primefaces - Ultimate JSF Framework..http://www.primefaces.org
Securing Web Applications - The Java EE 6 Tutorial. [Online]. Available:
http://docs.oracle.com/javaee/6/tutorial/doc/gkbaa.html. [Accessed: 08-Oct-2014].
Apache Shiro | Java Security Framework. [Online]. Available: http://shiro.apache.org/java-authenticationguide.html. [Accessed: 09-Oct-2014].
Spring Security. [Online]. Available: http://projects.spring.io/spring-security/. [Accessed: 09-Oct-2014].
Organization for Advancement of Structured Information Standard (OASIS), Security Assertion Markup
Language (SAML) V2.0 Technical Overview, Committee Draft 02, Mar. 2008.
OpenID Foundation website. .
D. Hardt, The OAuth 2.0 Authorization Framework. [Online]. Available: https://tools.ietf.org/html/rfc6749.
[Accessed: 07-Nov-2014].
J. Miller, Yadis Specification. 18-Mar-2006.
P. Mell and T. Grance, Electronic Authentication Guideline. NIST Special Publication 800-63 Version 1.0.2,
2011.

3
4
5
6
7
8
9
10
11
12
13