2012 IEEE 11th International Conference on Trust, Security and Privacy in Computing and Communications

FACIUS: An Easy-to-Deploy SAML-based

Approach to Federate Non Web-Based Services
Jens Kohler, Sebastian Labitzke, Michael Simon, Martin Nussbaumer, Hannes Hartenstein
Karlsruhe Institute of Technology (KIT)
Steinbuch Centre for Computing (SCC) & Insitute of Telematics
Zirkel 2, 76131 Karlsruhe, Germany
Email: {jens.koehler, sebastian.labitzke, michael.simon, martin.nussbaumer, hannes.hartenstein}@kit.edu
is common and, recently, became more ubiquitous. The number of established service federations is increasing and the size
of most of these federations is growing as well. In particular,
in the academic eld, SAML became a key technology for
federated identity management.
Unfortunately, SAML-based access control is not common
for non web-based services, such as cloud, grid, and high
performance computing resources or data facilities. In this
context, it is common to enforce access control via dedicated
accounts. Moreover, provisioning of accounts is often still not
supported by online registration processes. However, like webbased services, non web-based services can benet from being
easily accessible.
As many non web-based services are already operational,
it is unsuitable to design a new approach from scratch to
federate these services. Existing federations and services, as
well as the users have certain requirements that need to be
taken into account when federating the service. One of these
requirements is constituted by the fact that, as services rarely
establish a new federation, they need to be integrated into
existing AAIs. Therefore, the standards used in the respective
federation need to be adhered.
In this paper, we identify requirements that need to be
considered when federating non web-based services. Furthermore, we present FACIUS (Federated Access Control
Integration for Universal Services), an approach to integrate
Shibboleth/SAML identity providers (IdPs) with existing non
web-based services with regard to the identied requirements.
The concept aims to keep deployment effort as low as possible. Therefore, we used existing building blocks as much
as possible. We present a modular architecture based on
standardized interfaces that can be applied on different types of
non web-based services. Finally, we present an implemented
and operational proof-of-concept for accessing federated SSHbased services, such as grid and high performance computing
resources provided by third parties. In summary, the contributions of this paper are:
A list of requirements that approaches should aim to
fulll for federating non web-based services.
A exible approach to integrate non web-based services
with SAML-based federations that meets the identied
requirements. We show an evaluation with respect to
requirements, performance, security, and legal aspects.

AbstractFederated identity management yields many advantages such as enhanced usability and improved quality of identity
information. Web-based services are already successfully and
widely federated using the Security Assertion Markup Language
(SAML). In terms of usability and quality of identity information
non web-based services benet from being federated in a similar
way web-based services do. However, up to this point no versatile
approach that can be easily integrated has emerged to federate
them. In this paper, we present FACIUS, an architecture that
enables the integration of non web-based services into SAMLbased federations. FACIUS aims at minimizing the integration
effort in terms of both usability and necessary adjustments to
existing service deployments. Furthermore, to prove the practicability of the proposed architecture, we present an implementation
to federate SSH services.
Keywords-Federated identity management; SAML; Shibboleth;
non web-based services

I. I NTRODUCTION
The days pass by when the IT center of a company, or
rather an organization is able to provide any kind of IT service
required by their employees. Instead, those organizations join
service federations to get access to IT services provided by
third parties. Such outsourcing of IT services has been around
for a long time and has been inspired further by innovations
like grid and cloud computing. However, todays users demand
easy access to the services provided by other organizations,
i.e., access by the use of known and already existing accounts
administered by their own organization. In order to use these
accounts to access services provided by third parties, the
integration of the services into IT federations is required.
On the Internet, web-based services emerge that are using
authentication services provided by third parties, such as
Google or Facebook authentication. Furthermore, computing
centers and libraries of the academia deployed federations
for accessing web-based services using the Security Assertion
Markup Language (SAML)1 . Those institutions establish their
federations, or rather so called authentication and authorization
infrastructures (AAIs) by the use of Shibboleth2 or simpleSAMLphp3 (both are implementations of the SAML standard).
In general, federated access based on SAML-implementations
1 http://saml.xml.org/saml-specications
2 http://shibboleth.internet2.edu/.
3 http://simplesamlphp.org/.

978-0-7695-4745-9/12 $26.00 2012 IEEE

DOI 10.1109/TrustCom.2012.158

557

A proof-of-concept that applies FACIUS on an SSHbased service to demonstrate its operability.

The paper is structured as follows: In Section II, we
assemble requirements that an approach to federate services
should aim to fulll. Section III presents related work, before
Section IV introduces basics with respect to federated service
federations. In Section V, we present our approach FACIUS to
federate non web-based services. In this section, we introduce
the technical components of FACIUS, outline their interaction,
and explain the resulting architecture. In Section VI the
concept is applied on an SSH use case, whereas Section VII
evaluates and discusses the approach. Section VIII concludes
the paper.

II. R EQUIREMENTS
In order to derive the requirements that an approach to
federate non web-based services should fulll, we take SSH
services as a reference. In the following, the most important
requirements to federate an SSH service are presented and
generalized. We present demands of the users, the service
providers and the identity providers that can be used to
measure the feasibility of approaches, which federate non webbased services. Despite being deduced from the SSH use case,
the presented requirements are not specic for SSH and apply
for other services as well.
First of all, certain user requirements exist. Aside from
easier access to the service due to the federated nature of it,
the users expect to use the service in the familiar way (i.e., the
way they would use it if it was not federated). The following
requirements from the users perspective can be derived:
A transparent integration of the service into the federation is expected by users. That is, in case of an SSH
service, the users want to use their familiar SSH clients
without patching or upgrading them.
The users expect to be able to use the credentials of the
home organization to access the service. In this case, the
authentication of the user needs to be performed by an
identity provider instead of the service provider. We refer
to this as remote authentication in the remainder of this
paper.
Moreover, service-specic authentication methods should
still be usable. For instance, in case of SSH, public
key based authentication should be supported to preserve
the usability of the service. As in this case the service
provider authenticates the user, we refer to this as local
authentication in the remainder of this paper.
Furthermore, certain service provider requirements need
to be taken into account. The key requirements of service
providers are summarized in the following:
A major aspect for service providers is the deployability
of the approach. That is, the initial effort to federate a
service should be kept as low as possible. For instance,
the necessary implementation effort to apply the approach
to new services should be minimized.
Once deployed, the maintainability of the approach is
of importance to the service provider. For instance, this

includes patching or xing of software components that

are specic for the deployed approach.
Furthermore, service providers aim for an integration into
existing AAIs. Service providers rarely plan to build a federation from scratch and, therefore, depend on existing
identity providers. To use these identity providers, the
approach to federate the service should be based on a
widely used and accepted technology.
The level of security the federated service provides should
not be worse compared to the unfederated service. For
instance, in case of an SSH service it has to be considered
that logged on users do not have access to any critical
components. Furthermore, secure transmission of both
user credentials and user specic data has to be taken
into account.
Another important demand is that the performance of
the federated access control should not be unreasonably
worse than the performance of unfederated access control.
For instance, in case of an SSH service, small delays
during the login procedure are insignicant as long as
the user is not aware of them.
The provisioning of a local context is inevitable in many
cases. For instance, in case of an SSH service, a local
user account including a user identier (UID) to locally
identify the user and a home directory is necessary for a
user to access the service. Thus, an initial provisioning
of this context has to be regarded by the approach.
Likewise, the deprovisioning of local user contexts that
are no longer needed is an important aspect as well. It
is favorable to avoid the stacking of unneeded user
contexts. Furthermore, legal requirements might force the
service provider to delete user data if the user no longer
uses the service.
Finally, legal aspects are an important concern of service
providers. For instance, a service might require its users
to accept an acceptable use policy (AUP) before they are
granted access for the rst time. Thus, the service should
be designed in such a way that the service provider is
able to request the users consent to certain conditions.

Finally, certain identity provider requirements need to be

addressed:

Legal aspects are an important concern of identity

providers. For instance, in case of an SSH service that
needs the users organizational afliation to make an
authorization decision, local privacy laws need to be
adhered. To do so, identity providers might have to get
the users consent to release his personal data (e.g., his
organizational afliation).
Avoiding software adaptions is another important demand
of identity providers. For instance, as SAML identity
providers may participate in multiple federations, technologically the federations should not demand anything
from the identity providers besides a SAML interface.

In the following, existing approaches are evaluated by the

listed requirements. Furthermore, a novel approach to integrate

558

non web-based services into a federation (namely a SAML

federation) is presented and evaluated.

resources, whereas FACIUS is able to adapt several kinds of

services, such as grid, cloud, and high performance computing
resources. Furthermore, we present a modular concept that
allows different ways of authentication.

III. R ELATED W ORK

The project Moonshot4 aims at extending and combining components of common operating systems, such as the
Generic Security Service Application Program Interface (GSSAPI) [1] and the Extensible Authentication Protocol (EAP), in
order to federate access to non web-based services. In contrast
to FACIUS, the Moonshot approach integrates the components
with the existing RADIUS infrastructure Eduroam [2]. SAML
can be optionally used to retrieve attributes for authorization
decisions. Nevertheless, at this point in time Moonshot concentrates on mechanisms of the Eduroam infrastructure. Furthermore, the moonshot software requires a modied service
client at the user-side. Moreover, we present in addition an
approach for (de-)provisioning of local user contexts.
In the area of grid computing, several solutions to integrate
services with SAML-based federations emerged recently. The
authors of [3] and [4] presented federated login approaches for
specic grid infrastructures. They used the Shibboleth software
to federate web-based services in order to issue so called shortlived X.509 certicates. These certicates grant access to a
grid infrastructure for a xed amount of time. In contrast to
that, FACIUS constitutes a more generic approach that is not
limited to federate access to grid resources and that actually
federates the non web-based service accesses themselves. In
the context of grid federations, the authors of [5] give an
overview of the projects MyProxy and GridShib. Particularly,
within the GridShib project, SAML is used to retrieve user
attributes from a single and adapted Shibboleth IdP. However,
with GridShib, users are authenticated locally at the service
and authentications are based on certicates (see also [6]).
In contrast to that, FACIUS also allows authentications to
access the service based on an IdP login. Moreover, these
authentications can be performed by any unmodied SAMLIdP within an AAI. A major drawback of the access based on
certicates is that the service provider has to check revocation
lists to recognize if a user is already inactive or lost his access
rights. FACIUS provides various ways to access the service.
In each of these ways, the service provider interacts with the
IdP to recognize instantaneously if a user is deactivated.
The authors of [7] presented an approach to enable Pluggable Authentication Modules (PAM) [8] for X.509 certicates. Therefore, they extended OpenSSH5 to integrate their
proprietary PAM modules. In contrast to that, FACIUS enables
PAM to authenticate users with regard to a SAML-IdP. Furthermore, for the proof-of-concept, we did not need to extend
SSH servers themselves to integrate the PAM, which adheres
the PAM specications and can be deployed in popular SSH
servers by default.
In [9], the authors introduced a concept to federate grid
accesses based on similar components as used in this paper. However, the authors approach is dedicated to grid

IV. P RELIMINARIES
The SAML standard differentiates between the user, the
identity provider (IdP) and the service provider (SP). One of
the objectives of SAML is the cross-organizational exchange
of identity information. In short, the user is authenticated by
the IdP that in order to enable the SP to make an authorization decision issues assertions. Assertions are signed (and
optionally encrypted) user attributes that can be used by the SP
to decide whether to grant or deny service access. Furthermore,
the SAML standard differentiates between different use cases
(SAML proles). In the following, we briey explain the
proles, on which FACIUS is based on.
The WebSSO [10] prole is adapted to web-based services.
When accessing a service, the browser of the user is redirected
to a login page of the IdP carrying a SAML request signed
by the SP. Once logged in, the user gets redirected back to
the SP carrying the assertions issued by the IdP. Based on the
contained user attributes, the SP then grants or denies access.
The Enhanced Client or Proxy (ECP) [10] prole addresses clients that do not support browser specic procedures
such as redirects. The necessary steps to exchange identity
information have to be implemented manually, that is, to
retrieve the SAML request, to forward it to the IdP, to retrieve
the assertions and to forward them back to the SP. If the users
client itself implements the ECP logic, the client is called
enhanced client. If the ECP logic is implemented externally,
the component implementing the logic is called enhanced
proxy.
The AssertionQuery [10] prole allows SPs to request assertions about a user without involving him. The SP performs
the request by passing a persistentID to the users IdP. A
persistentID constitutes a unique identier for a combination
of a user, an SP and an IdP that has been established during
a previous WebSSO or ECP login of a user.
V. O UR APPROACH : FACIUS
A. Overview
An overview of FACIUS is given in Figure 1. In accordance
to the SAML standard, we distinguish between the user, the
service provider (SP) and the identity provider (IdP). For the
sake of modularity and security we furthermore differentiate
between nodes the user can get access to (Login-Nodes) and
the actual SAML service provider (SAML-SP). The SAMLSP encapsulates all SAML-specic logic of FACIUS and, to
enhance security, keeps the private key that is used to prove
the SPs authenticity to the IdP unreachable for a potentially
malicious user.
In some cases, it might be favorable to authenticate the
user against the SP instead of the IdP. For instance, consider
public key based authentication via SSH keys deployed at a
server (i.e., the SP). FACIUS distinguishes between two ways

4 http://project-moonshot.org/.
5 http://www.openssh.org/.

559

User
Browser

Service Provider
Login &
Registr.

RegistrationWebapp

Provisioning

In order to enable provisioning of local contexts such as

the UID or the home directory in case of an SSH service,
FACIUS leverages a web interface offered by the RegistrationWebapp. The user utilizes the Registration-Webapp to register
for the service before accessing it for the rst time. During
this registration process, both the IdP and the SP may request
the users consent for certain policies such as AUPs. The
Registration-Webapp and the AM are the only components
that interact with the federated service. Therefore, only an
adaption of the Registration-Webapp and the AM is required
to apply FACIUS on a service that has not been federated, yet.

Identity
Provider

SAML-SP
AssertionQuery-Stub
ECP-Stub

Login-Node
ServiceClient

RemoteLocalAuthn.

Service
Access
Point (AP)

Access
Control
Module
(AM)

Existing components

Generic components

Registration process

Login process

Fig. 1.

B. Provisioning workow

Partially service-specific
components

In order to use certain services, a local user context may be

required, which does not depend on federated user attributes.
For instance, a user needs an assigned UID and a home
directory to gain access to an SSH machine. This local context
has to be established by provisioning the necessary attributes
before the service can be accessed by the user for the rst
time. To achieve that, the user can register at the service via
a web interface of the SAML-SP (cf. Registration-Webapp
in Figure 1). The SAML-SP bases its authentication and
authorization decision on the resulting assertions of a standard
SAML-WebSSO procedure (i.e., the user authenticates himself
against the IdP and forwards the resulting assertions to the SP;
cf. Section IV). If the user is authorized to use the service,
the local context is generated and provisioned to a database.
Furthermore, a SAML-persistentID is bound to the user and
the SP is established with the IdP and stored at the database to
support the querying of user attributes without the involvement
of the user.
Notice that the Registration-Webapp is not restricted to mere
database provisioning. It is also possible for it to provision data
into conguration les or similar data structures, making it a
versatile approach.

Architecture overview

the user might authenticate himself: remote authentication and

local authentication. In case of remote authentication, the user
provides a password to be authenticated by the IdP. In case
of local authentication, the SP itself authenticates the user.
The authorization decision has to be based on assertions from
the IdP in either case. Otherwise a deployed SSH key would
grant a user access even if the IdP revoked a necessary access
qualication.
To enhance the deployability, FACIUS aims to minimize
the necessity to modify existing components. Therefore, given
an existing Service Access Point (AP) (e.g., an SSH server)
that can be accessed by the user utilizing an existing ServiceClient (e.g., an SSH client), FACIUS federates the service
by specifying an Access Control Module (AM). The AM
may use existing interfaces that are supported by the AP
to inuence the authorization decision (e.g., the Pluggable
Authentication Module (PAM) interface [8] in case of an SSH
server). Depending on the used authentication method, the
AM interacts with the SAML-SP to retrieve federated user
attributes. Whereas the use of the ECP prole is necessary for
remote authentication (cf. Section V-D), the AssertionQuery
prole is needed for local authentication (cf. Section V-E).
While the logic to retrieve user attributes via ECP is contained
in the ECP-Stub, the logic to request user attributes via
AssertionQuery is contained in the AssertionQuery-Stub. Both
the ECP-Stub and the AssertionQuery-Stub request assertions
from the IdP that is assumed to provide the necessary SAML
interface. Once the AM receives the user attributes, it bases
the authorization decision on them and forwards it to the AP
which grants or denies access to the user.
ECP-Stub and AssertionQuery-Stub are generic components
that are independent of the federated service and output user
attributes received from existing frameworks (see Section
V-C). The fact that these frameworks are independently maintained simplies the maintenance of FACIUS for the service
provider. Furthermore, neither needs the IdP be adapted, nor
is it strictly necessary to modify the native Service-Client
of the user. Therefore, an implementation of the proposed
architecture can be transparent for the user.

C. Stubs
In order to integrate a service provider into a SAML federation, some SAML-specic logic is necessary. To enhance
modularity and reusability, FACIUS encapsulates this logic
into the SAML-SP. The SAML-SP provides an interface that
is usable by the AM to authenticate a user against an IdP by
a provided password and to retrieve federated user attributes.
This interface is provided by the components ECP-Stub and
AssertionQuery-Stub. In order to keep the interface simple,
secure, and maintainable, we implemented the ECP-Stub and
the AssertionQuery-Stub as web applications. Thus, both
components are based on well understood technologies (e.g.,
Apache6 ) and protocols (i.e., SSL/TLS [11] and HTTP [12]),
which can be leveraged both for simplicity and security.
The ECP-Stub web application takes a user name and a
password as parameters and implements the ECP logic of an
enhanced proxy (cf. Section IV). It requests another resource
r which is protected by the Apache plugin mod shib (which is
6 http://httpd.apache.org/.

560

part of the Shibboleth framework). The resource r constitutes

a PHP script that simply reads an environment variable set
by mod shib and outputs the contained user attributes. To
access r, valid assertions of the IdP have to be conveyed to
mod shib. Using the provided credentials ECP-Stub retrieves
the assertions from the IdP and forwards them to mod shib.
After being granted access to r, ECP-Stub returns the user
attributes contained in the output of r. The mod shib module
is already commonly used to federate web-based services and
is independently maintained.
The AssertionQuery-Stub web application takes a persistentID as a parameter. It uses the framework simpleSAMLphp
to execute an AssertionQuery (cf. Section IV) and outputs the
resulting user attributes. The simpleSAMLphp framework is
maintained independently from our work.

ServiceClient

IdP

1
3
4

ServiceClient
3 2

Login-Node
5

SAML-SP

4
1

IdP

Login-Node
5 6

SAML-SP

SP

SP

(a) Remote authentication: SP as En- (b) Remote authentication: Servicehanced Proxy

Client as Enhanced Client

ServiceClient

IdP

4
5

Login-Node

6 3
SAML-SP
SP

D. Login via remote authentication

(c) Local authentication

In order to authenticate a user against the IdP based on a

username and a password, the SAML-ECP prole can be used.
The necessary logic to utilize the ECP prole can be placed
at the SP or at the Service-Client. In the following, these two
different (yet combinable) approaches will be presented and
discussed. First, we describe the use of the SP as enhanced
proxy. Afterwards, an approach that includes the customization
of a Service-Client as enhanced client is presented.
The login process when using the SP as enhanced proxy
is illustrated in Figure 2(a). In order to access the service,
the Service-Client sends the username and the password to
the Service Access Point (AP) which forwards it to the
Access Control Module (AM) (1). The AM then discovers
that remote authentication is used and passes the credentials
to the ECP-Stub of the SAML-SP (2). ECP-Stub then uses
the credentials to retrieve assertions from the IdP (3+4) and
outputs the contained user attributes to the AM (5). Based on
these attributes, the AM makes an authorization decision and
noties the AP. Finally, the AP grants or denies access to the
user, based on the decision of the AM.
While no modied Service-Client is needed to authenticate
via the SP as enhanced proxy, the solution might seem unfavorable in some cases due to the fact that the users password
travels through the SP. In order to tackle this drawback,
a modied Service-Client is necessary, since most ServiceClients trust SPs and rarely distinguish between SPs and IdPs
out of the box. In the following, the login process with a
modied (enhanced) client is presented.
The login process when using the Service-Client as enhanced client is illustrated in Figure 2(b). First, the enhanced
Service-Client tries to access the protected resource r of the
SAML-SP and retrieves a request for IdP-Assertions (1). Then,
the Service-Client forwards the request to the IdP (2) and
utilizes the user provided password to retrieve assertions from
the IdP (3). Afterwards, the assertions are conveyed to the
AM (4). Finally, the AM passes the assertions to the SAMLSP (5) and retrieves the user attributes from r on behalf of the
user (6). Based on the user attributes, the AM can make its
authorization decision.

Fig. 2.

Login scenarios

Whereas this approach requires a modied Service-Client,

the users credentials are not revealed to the SP. Furthermore,
notice that the two proposed approaches are combinable.
Therefore, the decision whether to entrust the SP with the
credentials and use a standard Service-Client or whether to
install a custom Service-Client and keep the credentials safe
can be made by the user.
E. Login via local authentication
In some specic cases, it is favorable to let the SP perform
the authentication of the user without interaction with the IdP.
For instance, it is possible to deploy a public key or an SPspecic password, which is bound to the user at the SP, during
the registration process. However, the authorization decision
still has to be based upon the assertions of the IdP to take
revoked permissions into account. With the AssertionQuery
prole, SAML provides the possibility to query attributes of a
user without requiring him to authenticate against the IdP. In
order to perform an AssertionQuery, a persistentID is needed
that has been established between the user, the SP and the IdP
beforehand. Such a persistentID is established and stored at
the database during the initial registration process (see Section
V-B).
The login process via local authentication is illustrated
in Figure 2(c). First, the user authenticates himself directly
against the AP (1). Afterwards, the AM retrieves the persistentID of the user from the database (2) and requests that the
SAML-SP performs an AssertionQuery (3). This is done by
accessing the AssertionQuery-Stub and passing the persistentID as a parameter. Based on the persistentID, the SAML-SP
performs an AssertionQuery (4), retrieves the assertions of the
IdP (5) and decrypts them. Finally, the AssertionQuery-Stub
outputs the contained attributes (6), which enables the AM to
make an authorization decision.
The use of the local authentication option has the advantage,
that no modied client is necessary and the SP does not learn
any user credentials that are managed by the IdP. However, in
case of local authentication via an SP-specic password the

561

In order to support remote authentication with the SP

as enhanced proxy, pam authenticate() passes the provided
user credentials to the ECP-Stub and makes an authorization
decision based on the returned user attributes. To enable
remote authentication with the Service-Client as enhanced
client, again the necessary logic (on the SP side) can be implemented in pam authenticate(). The SSH keyboard-interactive
mode can be exploited to communicate between PAM and the
modied SSH client through an unmodied SSH server.
To carry out a local authentication via an SP-specic
password, the password supplied by the requester is compared
to the SP-specic password that has been previously stored at
the database. Furthermore, the users federated attributes are
retrieved from AssertionQuery-Stub and based on them, an
authorization decision is made. Again, this logic can be implemented in pam authenticate(). In case of an authentication
via public key, pam authenticate() is no longer called, since
the SSH server executes the according challenge-response
protocol itself. Therefore, the call of the AssertionQueryStub and the authorization of the user has to take place in
the function pam session(), which is called right before the
beginning of the session and still allows to reject a user.
We implemented the proposed building blocks and used
them to federate access control on several SSH nodes. This
shows that FACIUS is fully applicable to federate SSH services.

user needs to keep track of multiple passwords for one account.

While this option is obviously unfavorable for everyday use, it
offers the opportunity to supply users with temporary (or even
one time) passwords. Furthermore, the local authentication
option offers the opportunity to authenticate against the SP via
challenge-response, which increases usability in many cases
(cf. public key authentication in SSH). Finally, it is possible to
support both local and remote authentication simultaneously,
allowing the user to choose whether he wants to authenticate
against the SP or the IdP.
F. Deprovisioning
The deprovisioning of contexts that are no longer needed
often constitutes a substantial problem for federated services.
This is due to the fact that SPs are not notied once the
permission to use a service is revoked by the IdP or the user
quits his relationship with the IdP entirely. This unidirectional
behavior is a major aspect of the federated approach itself
and has scalability and operability benets. Thus, changing it
would not only undermine the federated nature of the system,
but also lead to the loss of the mentioned benets.
To avoid the stacking of user contexts that are no longer
needed, the SP might consider deleting them after a certain time span of inactivity. This approach, however, is not
favorable for services that may not obligate their users to
login regularly. Another approach would be to mark user
contexts for deletion if their login failed due to the lack of
permission to use the service, signaling that the context is not
necessary anymore. However, if a user knows that he is no
longer permitted to use a service, he might not try to log on
again. In this case, the accordant user context would never be
deprovisioned.
FACIUS enables the SP to actively poll the IdPs for user
attributes by AssertionQuery and, therefore, allows the SP to
check if the user context is still needed at any time. As this
check is initiated by the SP itself, no customization of the IdPs
is necessary to support deprovisioning on short notice.

VII. E VALUATION & D ISCUSSION

A. Applicability
Although FACIUS builds on standardized interfaces and
frameworks, services must meet certain preconditions to be
federated. First of all, the service access point needs to
support PAMs or any other kind of interface to inuence
the authentication and authorization decision. Naturally, the
deeper the user management is rooted within the AP of the
service, the harder it is to federate the service using our
architecture. This is a minor drawback due to the fact that
services rarely implement their own user management and,
therefore, provide interfaces for external authentication and
authorization services.
In order to support a modied Service-Client while using an
unmodied AP, a communication channel has to exist to convey assertions from the Service-Client through the AP to the
AM. For instance, the transmitted password can be exploited
for this task if the assertions do not exceed its maximum
size. However, often more elegant ways such as keyboardinteractive mode in case of SSH exist to accomplish the task.
Notice that this precondition only applies for supporting a
modied Service-Client.
Using an unmodied Service-Client, the AM needs to get
access to passwords. Thus, only services that accept (encrypted) plaintext passwords support remote authentication
with an unmodied Service-Client, yet. This is due to the fact
that (considering the ECP prole) the Shibboleth backend is
currently only able to validate plaintext passwords. However,
one can expect that this changes in the future. Furthermore,

VI. A PPLICATION OF FACIUS ON SSH

In the following we show how we exemplarily applied
FACIUS to federate SSH access control on a Unix machine.
The provisioning of the user account is performed by the
registration process. The passwd entry of the account is stored
at a database along with the established persistentID as well
as the name of the users IdP and if desired an SP-specic
password. In order to enable the SSH server to read the passwd
entry from the database, the Name Service Switch (NSS) has
to be congured accordingly.
To be able to inuence authorization decisions, the AM is
implemented as a Pluggable Authentication Module (PAM) [8]
that can be used by an SSH server (e.g., OpenSSH) to
delegate the authorization decision. Particularly, a PAM offers
the two implementable callback functions pam authenticate()
and pam session() that are called upon authentication request
and successful authentication, respectively. The user-provided
credentials are passed to these functions.

562

of the service into a service federation. FACIUS ensures that

common authentication methods are still supported and can be
provided in parallel to the federated login.
2) Service provider perspective: An important point to
evaluate is how well FACIUS integrates with existing systems
on side of the SP. On the one hand, the effort to federate
a service based on components that are already implemented
can be evaluated (deployability), on the other hand the effort
to adapt components to federate other types of services can
be assessed (implementation effort).
From the deployability perspective, SPs need to install a
SAML-SP and to plug in an AM into their AP in order to
be federated. As the SAML-SP constitutes an independent
component, it does not inuence the existing service at all.
Depending on the interface of the AP, the AM may conict
with existing authorization mechanisms. However, in many
cases a seamless integration is possible. For instance, Unix
systems allow to use multiple PAMs at the same time. Therefore, besides the integration of the AM, no changes are needed
on the existing components of the service to federate it.
From the implementation effort perspective, the stubs do
not depend on the service to be federated and, thus, they can
be reused without further adaption. As different services require different local contexts, the registration web application
obviously needs to be adapted to the service. However, the
SAML-specic parts (i.e., the establishment of a persistentID)
can again be reused. Finally, different AMs may be necessary
for different services. However, the implementation does not
depend on the federated service, but on the interface to the
AP of the service. For instance, the PAM implementation
can be reused to federate services that allow delegating the
authorization decision to a PAM. Furthermore, the reusable
components of the SAML-SP offer a simple interface that
abstracts from the underlying SAML architecture (in fact only
a HTTPS [13] request is necessary). Thus, alternative AMs
need not implement any complex SAML-specic logic.
Another point to evaluate is the operational overhead that
FACIUS induces in terms of the maintenance effort. The ECPStub and the AssertionQuery-Stub are generic components
based on independent frameworks that are already continuously maintained. Thus, only the light weighted components
AM and Registration-Webapp have to be monitored and if
necessary xed by the service provider.
The fact that FACIUS builds upon already established
and well understood standards eases the security evaluation.
SAML supports strong cryptographic techniques to secure the
communication channel and uses certicates to validate the
identity of SPs and IdPs. Furthermore, it is possible to separate
the SAML-SP, which stores the secret key of the SP, from the
Login-Nodes to which users might get access (e.g., in case of
an SSH service). Therefore, the risk of theft of the SPs identity
by malicious users is reduced. Also, the implementation of
the SAML-SP components as web applications allows to rely
on established techniques such as TLS to ensure authenticity,
condentiality, and integrity.
However, in case of remote authentication via password and

Authentication
Remote Authentication
Local
Methods /
Unmodied Modied
AuthentiRequirements
Client
Client
cation
1) User perspective:
Familiar clients usYes
No
Yes
able
Login with credentials administered by
Yes
Yes
No
the home organization
AAI passwords only
No
Yes
Yes
accessible by the IdP
Operable in parallel
with service-specic
Yes
Yes
Yes
authentication methods
2) Service provider perspective:
Deployability
No major changes needed
Extensive use of standard components
Maintainability
maintained by third parties
Based on widely
SAML-based
used technology
Security
Enhanced by the use of SAML and TLS
Provisioning
Yes
Yes
Yes
Deprovisioning
Yes
Yes
Yes
Performance loss
700 ms
Legal Aspects
User consents can be requested
3) Identity provider perspective:
Legal Aspects
User consents can be requested
No need to modify
Yes
Yes
Yes
IdPs

TABLE I
E VALUATION RESULTS OF FACIUS WITH REGARD TO REQUIREMENTS
IDENTIFIED IN S ECTION II FROM THREE PERSPECTIVES

remote authentication with a modied client is not affected by

this, as the Service-Client has access to the plaintext password.
Also, local authentication is not affected as it does not depend
on the ECP prole.
Whereas certain characteristics need to be considered to
apply FACIUS, they do not constitute decisive factors to
implement and deploy our approach.
B. Evaluation with regard to requirements
With regard to the requirements discussed in Section II, we
evaluate FACIUS from the perspective of the users, SPs, and
the IdPs. Table I presents an overview of the evaluation results
that are discussed in the following.
1) User perspective: First, we stated that users expect to
be able to use their familiar clients to get access to federated
services. Aside from the enhanced client option, FACIUS is
transparent to the user in terms of login. Users can get access
to the federated services using their familiar client without
installing any new software components for both remote and
local authentication. In general, login credentials administered
by the users home organization can be used for the cases of
remote authentication. However, if a user likes to prevent that
these credentials, which are used for remote authentication at
an IdP, travel through the SP, a modied client is needed or
local authentication has to be used. A further requirement for
federating non web-based services is that service-specic authentication methods will not be disabled due to the integration

563

without a modied client, the users federated password travels

through the Login-Node in plaintext. At this point, possible
risks include a malicious or compromised SP. Whereas existing
(unfederated) services suffer from exactly the same problem,
it has more weight in the federated case. An eavesdropped
password not only grants the attacker access to the considered
service, but all federated services accessible by the user.
FACIUS proposes multiple ways to log on to the service that
do not reveal federated credentials to the SP. In fact, even a
combination of login alternatives can be offered to the user.
For instance, in case of an SSH service, users may get an (only
locally valid) one time password after the registration process
which they can use to log in once and deploy their public key.
To give an impression of the performance of our approach,
we measured 100 regular and 100 SAML-enabled, sequentially performed SSH logins (remote authentication + SP as
enhanced proxy). While a regular SSH login took 0.24 seconds
on average (0.95 condence interval: 0.004), a SAML-enabled
SSH login took 1.01 seconds (0.95 condence interval: 0.013).
Compared to the regular SSH login, multiple messages have to
be exchanged between the IdP and the SP during the SAMLenabled SSH login in order to execute the ECP prole. Thus,
the overhead induced by the SAML-enabled SSH login is
inuenced by the computational overhead to encrypt and sign
these messages, the network latency and the time the IdP needs
to retrieve the users attributes from the according identity
management system. Whereas, the choice (and therefore the
response time) of the deployed identity management system
may vary for different scenarios, the measurements indicate
that federating non web-based services utilizing SAML is
feasible.
Furthermore, SPs may want to impose Acceptable Use
Policies (AUP) on its users. The AUP can be presented and
the consent of the user can be requested during the registration
process on the web interface.
3) Identity provider perspective: A service that is federated
by the use of FACIUS does not require a modied IdP. For
instance, in case of a Shibboleth IdP, just ECP has to be
enabled within the conguration of the IdP.
Our approach allows the SP to poll user specic data from
the IdP, which might conict with local data privacy laws.
However, notice that it is easily possible to request the users
consent in the initial registration process. For instance, the
Shibboleth plugin uApprove7 allows IdPs to let users approve
that certain attributes are released to the SP. Therefore, the
potential privacy conict can be mended in many cases.

service. In order to perform authentication and authorization

of a user in a SAML federation, several combinable building
blocks have been proposed and tradeoffs between usability and
security have been evaluated. While FACIUS allows the user
to use standard clients to access the federated service, the user
may also use a modied client to protect his password from
an untrusted service provider. As the proposed modularized
architecture builds upon existing standards, it allows an easy
integration of existing services. Furthermore, maintenance is
simplied, as our solution is based on externally maintained
frameworks to a large extent. In the future, we aim to address
the fact that services need to support basic authentication
(plaintext password validation) in order to be integrated
into Shibboleth infrastructures. Moreover, we plan to apply
FACIUS on further services.
ACKNOWLEDGMENT
The results presented in this paper are based on the work within the
project bwIDM that aims at providing identity management solutions
to ease the access to non web-based services provided by universities
of the state of Baden-Wurttemberg, Germany. The authors would
like to thank the bwIDM project partners as well as the Ministry of
Science, Research, and the Arts of the State of Baden-Wurttemberg
(further information: http://www.bwidm.de/).

R EFERENCES
[1] J. Linn, Generic security service application program interface - RfC
1508, United States, 1993.
[2] M. Milinovic, J. Rauschenbach, S. Winter, L. Florio, D. Simonsen,
and J. Howlett, Deliverable DS5.1.1: eduroam service denition and

implementation plan, GEANT2,

Tech. Rep., 2008.
[3] J. Basney, T. Fleury, and V. Welch, Federated login to teragrid, in
Proc. of the 9th Symposium on Identity and Trust on the Internet (IDtrust
2010), Gaithersburg, Maryland, USA, April 2010, pp. 111.
[4] R. Murri, P. Z. Kunszt, S. Mafoletti, and V. Tschopp, Gridcertlib: A
single sign-on solution for grid web applications and portals, J. Grid
Comput., vol. 9, no. 4, pp. 441453, Dec. 2011.
[5] T. Barton, J. Basney, T. Freeman, T. Scavo, F. Siebenlist, V. Welch,
R. Ananthakrishnan, B. Baker, M. Goode, and K. Keahey, Identity
federation and attribute-based authorization through the Globus Toolkit,
Shibboleth, Gridshib, and MyProxy, in Proc. of the 5th Annual PKI
R&D Workshop, Gaithersburg, MD, USA, April 2006.
[6] C. Grimm, R. Groeper, S. Makedanz, H. Pfeiffenberger, P. Gietz,
M. Haase, M. Schiffers, and D. Ziegler, Trust issues in Shibbolethenabled federated grid authentication and authorization infrastructures
supporting multiple grid middleware, in 3rd Intl Conf. on e-Science
and Grid Computing (e-Science), Bangalore, India, December 2007, pp.
569 576.
[7] A. Qin, H. Yu, C. Shu, and B. Xu, XOS-SSH: a lightweight user-centric
tool to support remote execution in virtual organizations, in Proc. of the
1st USENIX Workshop on Large-Scale Computing (LASCO08), Boston,
MA, USA, June 2008, pp. 1:11:10.
[8] V. Samar, Unied login with pluggable authentication modules (PAM),
in Proc. of the 3rd ACM Conference on Computer and Communications
Security (CCS), New Delhi, India, March 1996, pp. 110.
[9] F. Pinto and C. Fernau, An approach for Shibboleth and grid integration, in Proc. of the 4th UK e-Science Programme All Hands Meeting
(AHM), Nottingham, UK, September 2005.
[10] J. Hughes, S. Cantor, J. Hodges, F. Hirsch, P. Mishra, R. Philpott, and
E. Maler, Proles for the OASIS Security Assertion Markup Language
(SAML) V2.0, OASIS Std., March 2005.
[11] T. Dierks and E. Rescorla, The transport layer security (TLS) protocol
version 1.2 - RfC 5246, 2008.
[12] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and
T. Berners-Lee, Hypertext transfer protocol HTTP/1.1 - RfC 2616,
1999.
[13] E. Rescorla, HTTP over TLS - RfC 2818, 2000.

VIII. C ONCLUSION
In this paper, we presented FACIUS, an approach to federate
access to non web-based services using SAML, and applied
it exemplarily to federate SSH services. The approach allows
a user to register via a web interface, which can be leveraged
both for provisioning a certain context the service might need
locally and to get the users consent to submit his data to the
7 http://www.switch.ch/aai/support/tools/uApprove.html.

564