Secure idenTity crOss boRder linKed - eLearning and Academic

Qualifications Pilot at IST

Simon Esposito
[Link]@[Link]

Instituto Superior Técnico, Lisbon, Portugal

June 2015

Abstract
The demand for federated identity management systems is growing. With the current thrive of
online services on the web, the interest of governments in offering online public services for citizens
and organizations is on the rise. This creates the need for digital identity management systems that
can provide a high level of authentication assurance while keeping the risk of using such services at a
minimum. The Secure idenTity acrOss boRders linKed (STORK) Large Scale Pilot (LSP) has been
presented as a solution to this demand, by creating a unified European electronic identification and
authentication area between the European Union (EU) Member States (MSs). In this work we will
present the proposed solution and implementation of Within the scope of the academic STORK LSP.

Keywords: STORK, Identity Management System, Federated Identity Management, Federated

Attribute Exchange, eGovernment services.

1. Introduction the United Kingdom) that still don’t provide any

type of Identity Card implementation at all.
The STORK project1 aims at creating a single dig- Because of the heterogeneous IdM solutions al-
ital identification and authentication area over Eu- ready adopted by those MSs, interoperability be-
rope, establishing electronic Identities (eID’s) for comes an issue as many different technologies are
individuals and legal entities. used leading to the demand for a federated stan-
To achieve this goal, the interoperability of elec- dardization of such systems [9]. This arises other
tronic Identity Management Systems (IdMs) across problems such as: legal issues; assuring the user
the European MSs is crucial. Countries like Aus- privacy across the different IdMs transactions; give
tria [12, 7, 10], Estonia[8, 5], Finland[11], The the user information about the policies of release of
Netherlands and others already have IdMs in place his attributes; enforcing these policies at the Service
that were implemented without the establishment Providers (SPs); and allow the user to maintain his
of clear common goals across the EU. This has anonymity (to an extent). Moreover, for usability
caused a high heterogeneity of implementations purposes, the user shouldn’t need to authenticate
which makes interoperability difficult and poses sev- to all IdMs individually, but instead, a relation of
eral security and privacy challenges. trust should exist between organizations to provide
Some MSs also deployed SmartCards (SCs) for Single Sign On (SSO) across them in order to mit-
their citizens [1] which function as electronic iden- igate this issue.
tity cards. These cards are called European Citizen For the project to succeed, a reasonable level of
Card (ECC), and have built-in support for the Pub- assurance must be given in order to let them build
lic Key Infrastructure (PKI) enabling Electronic trust in the system and let them rest assured that
Identities (eIDs). This means that these eID cards their data is securely protected and safely delivered
provide the necessary functionalities to citizens that across MSs. The residual risk of using the system
allows them to authenticate with high assurance to will only be accepted by citizens and organizations
online services. However, there are countries (e.g. if a certain level of trust, assurance and usability is
achieved, enabling the uptake of the system.
1 [Link]

1
2. Background single place; which is also a security threat as the
centralized IdP is a single point of failure.
2.1. Federated Digital Identity
An identity federation is an established partner- Federated Model
ship between organizations, countries or any num-
The federated model establishes an identity fed-
ber of entities to allow the exchange of individu-
eration where SPs rely on any IdP within it. By
als identities information and attributes using com-
relying on the trust network established, the SP
mon agreed namespaces, protocols and technologies
might even not previously know the IdP where a
to enable interoperability and create a network of
user authenticates. This has many advantages:
trusted relationships between the federation mem-
SPs need not store any user information, enhancing
bers. Because federations involve multiple organi-
privacy and being more cost-effective. It provides
zations, problems such as liability, trust and secu-
SSO functionality across different SPs, enhancing
rity become much more relevant [3], as many more
usability and overall security for the user. A
stakeholders are involved in a federation, making
drawback of this model is the introduction of the
federated digital identity management much more
IdP discovery problem. Another is that, since
challenging than managing eIDs within a single or-
the user information might be scattered across
ganization, even if at a multi-domain level.
different IdPs, a solution for attribute aggregation
2.2. Identity Management Models must be implemented. These drawbacks introduce
additional complexity to the system but alleviate
IdM models can be divided into four categories:
the SPs from identity management altogether,
isolated, centralized, federated and decentralized
having to exclusively manage the federation trust
(distributed) [2, 4, 13].
network (which usually involves the PKI).
Isolated Model
Distributed Model
In the isolated model, the Identity Provider (IdP)
In the distributed model, the IdP is a security to-
and the SPs are the same entity. This is the
ken (such as a SmartCard, SIM card or any other)
most common model currently on the Internet,
held by the user itself. The credentials are se-
where SPs are responsible for the management of
curely stored in the token and are released upon
their users credentials. This model is the most
user authentication through a Personal Identifica-
popular, but also the one with the most drawbacks:
tion Number (PIN) upon request. These tokens are
it is very burdensome for the users, which need
issued by a trustworthy entity (such as the govern-
to remember their credentials for each SP, often
ment or a national bank), which validate the trust-
leading to poor/insecure password choices, hence
worthiness of the stored credentials. This is the
lowering security; it is also burdensome for the
model that gives more control to the user over his
SPs themselves, as managing user credentials
credentials because he is in possession of the tokens.
has infrastructure and security costs; and finally,
A disadvantage however, is that SPs need to handle
SPs control over credentials might disclose the
a possible wide range of different tokens and the in-
user private information without consent, leading
herent technologies and standards. The tokens also
to privacy loss. SPs often claim to protect the
have other problems: they usually have little stor-
users privacy through Privacy Policy Agreements
age capacity (e.g: SmartCards) and also, the secure
(PPAs), but to what extent they are enforced is
update of outdated credentials within the tokens is
often a grey area.
difficult. These solutions have to rely on distributed
Attribute Providers (APs) (the tokens) and addi-
Centralized Model tionally have to face discovery and attribute aggre-
The centralized model separates the IdP and SPs gation problems.
roles, having a single centralized IdP that stores all
the users credentials/attributes. This is often used 2.3. The Portuguese IdM Architecture
in mid-to-large organizations where SSO solutions The Portuguese national IdM relies on its infras-
are in place, alleviating some of the burden of the tructure and the European Citizen Card (ECC) is-
users having to manage multiple credentials, as sued to all citizens as an authentication token. The
they will use the same set across all the services eID SmartCard contains two digital public key cer-
provided within the organization. It also alleviates tificates: one for user authentication and another
the management of credentials on the organization for digitally signing documents. Both functionali-
itself, as it eases the management of high numbers ties are protected by PIN codes that are sent to the
of users by having a single place of storage. This citizens via a secondary channel (postal service) so
model however, suffers even more of the privacy that they are more difficult to compromise, as an
issue, as more data of the user is stored in a identity thief would need to have access to both

2
the eID and the PIN number to be able to commit middleware to authenticate the user. If some citi-
fraud. zen’s attributes were also requested by the SP, if
The national IdM is called SCAP (Sistema de they are available on the government’s database
Certificao de Atributos Profissionais - Certification (e.g.: the citizen’s address or NIC) they are re-
System for Professional Attributes). The global ar- trieved by SCAP, otherwise the request is relayed
chitecture of SCAP can be seen on figure 1. to the PIAP.
The Plataforma de Interoperabilidade da Admin-
istracao Publica (PIAP) is the component that es-
tablishes secure connections with all the APs using
a Simple Object Access Protocol (SOAP) web ser-
vice. When an attribute request is received, the
PIAP asks all the APs it knows for attributes, re-
ceives them and sends them back to Sistema de Cer-
tificao de Atributos Profissionais (SCAP).
The attributes aren’t signed by the APs them-
selves, but instead, SCAP is responsible for the dig-
ital signature of the attributes retrieved from the
possible several APs. The signature keys are es-
tablished when an AP joins the infrastructure and
Figure 1: SCAP global architecture. are always stored by SCAP. This way the APs only
need to worry about securing the connection with
The goal of SCAP is to provide a national sys- the PIAP, but not with private key management,
tem to enable citizens to retrieve digitally certified which is all centralized and controlled by Agncia
attributes from other public institutions or APs. para a Modernizao Administrativa (AMA).
The attributes can then be consumed by service This leads us to the function of the Hardware
providers as credentials. An example would be the Security Module (HSM), an hardware component
release of an attribute stating that a citizen is a for cryptoprocessing that signs the attributes with
civil engineer, since this attribute is certified by an- the private key of the respective AP.
other national institution called “Ordem dos En- After all the above processes are terminated, the
genheiros” (OE) which is responsible for qualifying SAML Response is constructed with the signed as-
civil engineers with the entitlement to sign charters. sertions and it is returned to the requesting SP.
As can be seen in Figure 1, the system is com- This overview doesn’t include the integration
prised by several different modules and frameworks, with STORK, which requires, among other work,
but on this document we will only discuss the most the deployment of the national PEPS and its con-
relevant: nection with the infrastructure described above.

• FA: Citizen authentication module; 2.4. Secure idenTity crOss boRders linKed
The STORK project [14, 6] aims to solve the prob-
• PIAP: Interface with APs module; lems not addressed by MODINIS, while keeping the
key features of the PRIME Project, allowing an Eu-
• HSM: The Attribute Signature hardware ropean citizen to access eGovernment services and
module; other SPs belonging to institutions and organiza-
tions residing in other MS, authenticating to them
The FA module allows a citizen to authenticate using an ECC card or some other token issued in his
himself using his Portuguese ECC with a Smart- residing MS. This implies the roaming of a citizen’s
Card reader plugged into his computer and hav- attributes across different European countries.
ing the provided middleware installed on the ma-
chine. When a SP requests authentication, the 2.4.1 Architecture Components
user’s browser is redirected to the FA using the The STORK architecture is comprised by two
SAML Web Browser SSO Profile. The FA web page main components: the middleware and the PEPS
loads a signed Java applet that is executed by the (Pan-European Proxy Service). The former is a
browser (after asking the user if he trusts the signa- middleware that is installed on SPs and IdPs and
ture used to sign it and the applet itself). The ap- allows them to communicate directly; the latter
plet then communicates with the SmartCard reader is a network of proxies that act as intermediaries
and prompts the user for his PIN number to get ac- for cross-border identity requests, creating links of
cess to the ciphered information within the ECC. trust between MSs and bridging the isolated “is-
A token with the user’s identity is released from lands” that form the national IdM infrastructures.
the ECC and sent securely to the FA through the These two components can function seamlessly

3
together, rendering the STORK infrastructure where he is from on the S- PEPS through a Where
capable of handling both the centralized and Are You From (WAYF) interface), that in turn
distributed models. The data format used to is responsible to route the request to the correct
exchange authentication and attribute information national IdP (3). The IdP sends the response back
in the communications between PEPS and related to the C-PEPS (4), which then sends it back to the
entities (SPs and IdPs) is the Security Assertion requesting S-PEPS (5). The S-PEPS asserts to the
Markup Language (SAML) standard, and the SP that a user has been successfully authenticated
messages are sent using a Representational State on the IdP by sending back the SAML response
Transfer (RESTful) approach. (6), otherwise an error message is sent. If the SP
also requested some user’s attributes on step (1),
The PEPS Model the S-PEPS queries the user if he authorizes such
request before step (2), and when receives the
This model relies in a network of proxies estab- response from the C-PEPS in step (5), prompts the
lished within the EU. At least one proxy per MS user again to authorize the release of the attributes
is necessary at a national level, which is responsi- to the requesting SP.
ble to bridge the national IdM infrastructure with
the PEPS network of proxies. This allows establish-
ing an interoperability layer on top of the different The middleware Model
MSs deployed infrastructures that abstracts from The middleware component enables the decentral-
the specificities of the individual solutions. This ized deployment of STORK. It has the advantage
model scales well not only because of this abstrac- of providing better privacy and end-to-end security.
tion, but also because it creates a system of trust re- Despite the advantages, the decentralized model
lay, where each MS only needs to manage the trust faces scalability issues because it forces SPs to have
relation between the national PEPS proxy and the to support the different foreign eID tokens that ex-
existing national IdM infrastructure by inherently ist, which may be based on different protocols and
trusting in the network of PEPS proxies. Fig. 2 technologies. To support these requirements, the
shows an example of the trust circles that are cre- middleware component has a modular and exten-
ated by the PEPS model and its basic process flows. sible design, so that the different IdM technologies
support can be added through modules to the core
component, called Modular Authentication Relay
Service (MARS) or the (Virtual Identity Provider)
VIDP core. The structure of the MARS can be seen
in Figure 3.

Figure 2: Trust networks in the PEPS model. In

this example, an Italian SP is trying to access a
Spanish IdP. The Italian SP trusts the respective
national PEPS, that in turn trusts the Spanish
PEPS, which trusts the Spanish IdP. This trust
relay solution minimizes the management of trust
relations, allowing the PEPS model to scale to a
European level.

The process flow and basic function is described

in Figure 2. A PEPS server can either act as a Figure 3: Modular Authentication Relay Service
so-called S-PEPS (PEPS in the state of the SP) or (MARS). Adapted from [14]
as a C-PEPS (PEPS in the state of the citizen).
This nomenclature specifies the role of the PEPS The core component is responsible for handling
in a given transaction: the S-PEPS receives an the SAML messages, logging and runtime deploy-
authentication request from a SP (1) and acts ment of the extension plug-ins and plug-ons. These
as the intermediary that routes it to the correct extensions allow the implementation of the country-
C-PEPS (2) (this is achieved by querying the user specific national IdM components (also called SP-

4
Ware) to integrate them into the STORK infras- then contact the C-PEPS (acting as a stub) in
tructure. The plug-ons and plug-ins must imple- Spain, that would then act as intermediary for
ment two MARS interfaces, respectively: The Java the Spanish IdP using the SAML protocol.
and the SPWare interfaces. The former handles in-
coming authentication and attribute requests from Spain to Spain: For a national request within
the SPs by implementing the necessary protocols Spain, the national SP would contact the na-
to interpret them (e.g: SOAP for the German SPs tional S-PEPS to route the request to citizen’s
and REST for Austrian SPs), and route them to respective country (Spain in this case). The SP
the latter, which is implemented by the SPWare would create the SAML Request and send it to
connectors that are responsible for implementing the S-PEPS running the VIDP, which would
the necessary technology to connect to the national- route it to the C-PEPS connector, redirecting
specific IdM infrastructure. Figure 3 illustrates the it to the C-PEPS. To note that in this case
German and Austrian Java plug-ons, as well as the the S-PEPS and the C-PEPS are essentially
respective SPWare connectors for the German (eID the same middleware running on the same ma-
Service) and Austrian MOA-ID IdMs. chine, as the middleware would act as both en-
As seen in Figure 4, the VIDP has a S-PEPS in- tities in the case of a non cross-border use case.
terface and a C-PEPS connector. This is because Spain to Austria: Finally, in a Spain to Austria
the middleware also supports the centralized PEPS scenario, picture an Austrian citizen trying to
model, and is in fact running in the proxies them- access a Spanish SP would trigger the SAML
selves, allowing interoperability between the cen- Request to the national S-PEPS. Because Aus-
tralized and distributed model the mix model. For tria has a decentralized model, the Spanish S-
the middleware to support both the distributed and PEPS would act a proxy/stub to the MOA-ID.
centralized models, the following components are Once the request reaches the VIDP through
part of the middleware architecture: the V-PEPS interface, the MOA-ID connector
would be used to directly connect to the Aus-
V-PEPS: This plug-on is responsible for receiving
trian IdP .
STORK authentication requests messages from
a S-PEPS. Note that in the above examples the route that the
C-PEPS Connector: The C-PEPS connector SAML Response would take has been omitted, as
plug-in is the endpoint of the VIDP that routes it would be the inverse of the request. The return
a S-PEPS request to the citizen’s country C- flow has also been omitted from the diagram in Fig.
PEPS. 6 for simplification.

These components create the necessary condi-

tions to enable full interoperability of the STORK
infrastructure for countries that have either cen-
tralized or decentralized IdM architectures. As
seen in Figure 4, Spain has a centralized model,
against the decentralized approach of Austria. The
diagram shows how the middleware behaves in 4
possible SP to IdP pair interactions:

Austria to Austria: In this case, the SP would

contact the national infrastructure running the
MARS middleware using the SP AT Interface.
Since an Austrian citizen made the request, the
VIDP would route the request to the MOA-ID
connector.
Figure 4: Mix Model Distributed and centralized
Austria to Spain: Imagine a Spanish citizen models integrated by deploying the stub/proxy of
wanting to access an Austrian SP. Once again the distributed model in the centralized systems.
the SP would make the request to the MARS
middleware through the SP AT interface, but
this time, because the IdP is in Spain (which 2.4.2 Quality Authenticator Model
uses a centralized infrastructure and relies on To create a single authentication and SSO area
the PEPS model), the VIDP would route the within the EU, mechanisms to control the qual-
request to the C-PEPS Connector, that would ity and assurance of a given authentication need

5
to be established. The variety of technologies used the lower AQAA level within the set is to be ap-
within the countries with functional IdM infrastruc- plied. This is because the weakest AQAA in the set
tures leads to different quality levels of authentica- defines its trustworthiness as a whole.
tion and quality assurance depending on the tech-
3. Implementation
nology used. For example, a username/password
tuple is the weakest type of authentication, while 3.1. Trusted Attribute Display Service
cryptographic physical tokens (such as the various The Trusted Attribute Display Service (TADS)2 is
tokens with PKI features in Austria, or the ECC in a web application that relies on the STORK infras-
Estonia/The Netherlands or Portugal), provide the tructure (using the Pan-European Proxy Service
strongest authentication method. (PEPS) model) for authentication and attribute re-
In such a diversified environment, it is important trieval. The goal of TADS is to give European cit-
for SPs to be able to determine what is the strength izens a tool that allows them to materialize on pa-
of the technology that was used to authenticate a per the digital attributes that they retrieve from
given user before authorizing access or consuming STORK, enabling the dematerialization of identity
his attributes. This way, the SP can estimate the assured credentials with legal validity in a MS, and
risk of giving access to a sensitive service depend- materialization into another, thus establishing a
ing on the strength of the authenticated technology trust circle between digital and printed documents.
used. TADS is to be deployed as a trusted SP, where users
To solve this problem, the Quality of Authentica- can retrieve and gather several attributes (primarily
tion and Assurance (QAA) levels were designed as academic) from different APs, and aggregate them
an important part of STORK. There are four QAA into a signed, printable Portable Document For-
levels, 4 being the highest (authentication using an mat (PDF) document. They can then present a
ECC) and 1 the lowest (authentication through a printed or digital version of the document to the
username/password tuple). verifier (whom is interested in verifying the docu-
Because the attributes retrieved from the ment validity), which will access the TADS service
STORK infrastructure may be released from several for validation. If the verifier receives a digital ver-
different IdPs, they suffer the same assurance prob- sion of the document, he only needs to check the
lems as the authentication methods themselves, as validity of its digital signature. A Quick Response
some IdPs may be more reliable than others, and (QR) code on the printed documents allows the ver-
the individual attributes may also have different as- ifier to scan them using a webcam from the TADS
surance levels. For example, a university may re- verification service page and retrieve the digitally
lease the address of a student, however, this infor- signed PDF document, thus allowing him to vali-
mation may be outdated, making it unreliable and date the document and the contained credentials.
lowering its assurance. If, however, this information Figure 5 shows an overview of the involved entities
was provided by a government IdP that retrieved and interactions in an exemplified usage flow.
the attribute from the national residents registry, it
would have a higher level of assurance. The same
may not apply to a student’s diploma though, be-
cause this information is managed by the university
itself, giving it maximum authority over its disclo-
sure, which gives it the highest level of attribute
assurance.
To enable IdPs to specify the assurance level of
the individual attributes, the Attribute Quality of
Authentication and Assurance (AQAA) were de-
signed, based on the QAA, and having the same
four levels of assurance that directly map to the
QAA levels. This permits that when an authen-
tication is combined with multiple attributes, it is Figure 5: TADS interaction flow overview.
possible to make a separate statement of the AQAA
level for all the individual attributes as well as the 3.1.1 Software Architecture
QAA of the eID level, giving SPs fine grained con- The software architecture of TADS is presented in
trol over under what circumstances they would au- Figure 6. [Link] applications are composed by
thorize a user or accept his attributes for a given modules provided by the community that are man-
operation, letting them have some control over the aged through the NPM (Node Package Manager)
associated risk. In situation where a single AQAA
level statement is to be applied to a set of attributes, 2 [Link]

6
tool. The most relevant modules are represented in wrapper class created specifically for Trusted At-
the figure. We will briefly describe those modules tribute Display Service (TADS). This is to expose
and other components. a simpler API to interact between [Link] and the
library.
Node-java Module: Because the provided SAM-
LEngine library is in Java, this node-java module
is necessary to be able to bridge the [Link] appli-
cation and the library API. The module allows a
Java class to be instantiated from the [Link] ap-
plication and creates the necessary data bindings to
directly interact with it.
SignServer3 is an open-source application frame-
work written in Java that allows to perform a wide
range of cryptographic operations for other appli-
Figure 6: Architecture of TADS. cations. For TADS, it acts as a local server that
exposes a REST API that is invoked by TADS to
Simple and Complex Attributes: TADS allows add a cryptographic signature to the user created
the user to create a PDF containing either simple documents.
or complex attributes retrieved from the infrastruc- 3.2. e-Learning Application
ture. Simple attributes are just key-value pairs, The eLearning pilot at IST is integrated with
making it easy to interpret and insert into the PDF. the institution’s academic web platform (FenixEdu-
Complex attributes are more complex XML struc- Academic) and the Central Authentication Service
tures that require additional processing. (CAS) deployment. The system will allow a for-
To uniquely identify the users in the system and eign student to access an online course on the Fenix
keep track of their documents, the eIdentifier at- platform by authenticating at the IdP of his coun-
tribute is used, as it uniquely identifies a citizen try of origin and obtaining the necessary credentials
within the infrastructure. For this reason, the at- that prove his enrolment in the course through the
tribute is always requested as mandatory alongside STORK infrastructure, granting him access to its
authentication. contents and resources.
[Link] is a framework that provides Applica-
tion Programming Interfaces (APIs) to develop web 3.2.1 Software Architecture
applications on top of [Link] following the Model- Figure 7 shows the overall architecture of the appli-
View-Controller (MVC) architectural pattern. It cation.
gives the developer the necessary tools to easily
manage the web application routing and middle-
ware components that handle things such as the
views template engine, cookie and session manage-
ment and serving static files.
MongoDB is a NoSQL document-oriented
database that follows a schema-less model where
documents are stored in structures that are very
similar to JavaScript Object Notation (JSON).
STORK SAML Engine Library is a Java li-
brary that provides an API for SPs to create and
validate SAML Requests and Responses in the con- Figure 7: eLearning architecture overview.
text of the STORK project. The SP needs to con-
figure the SAMLEngine in collaboration with the The involved entities are the following:
national entity responsible for the deployment of
the PEPS, as it is necessary that the PEPS trusts • Fenix-edu Academic platform: This is where
the SP, meaning that the SP public key certificate the course will be created and hosted. The
used to sign the SAML Request needs to be added platform provides the tools to maintain and
to the PEPS keystore, among other parameters re- manage all the necessary information to run
garding namespaces and the SP identifiers that are the course and its contents;
used to log the SAML transactions.
• Central Authentication Service: This is the
STORKTADSUtils class: As seen in Figure 6,
SSO server deployed at IST that is used for
the [Link] application doesn’t invoke the STORK-
SAMLEngine library directly, but instead uses a 3 [Link]

7
 access control and authorization for all the ser- is redirected back to the CAS server after going
vices offered by the informatics department, through the STORK authentication and attribute
including Fenix. This means that it has to retrieval flow. The SAML Response comes within
be connected to the STORK infrastructure to the HTTP request as an URL parameter. The nec-
make it accept STORK attributes as creden- essary web flow was set up so that if a SAML Re-
tials and grant the user access to Fenix and its quest parameter is detected, it is routed to the cus-
eLearning course; tom authentication handler created for the SAML
validation.
• The national PEPS and the STORK infras-
tructure. 3.2.3 FenixEdu-Academic Integration
Creating and enrolling a student on-demand in the
Academic is one of the modules of the FenixEdu STORK course on Fenix requires a number of steps.
software platform and it allows to manage curricu- Some of these steps are workarounds, because the
lar units within the university. The platform is ac- platform doesn’t support capacities and on-demand
cessible from a web browser by students and teach- enrolments due to its business rules being aligned
ers giving them access to interfaces that allow them with the processes of the institution.
to see and manage the courses contents. Authentication is the responsibility of CAS,
For the eLearning pilot, a course called which includes authentication through a SAML
STORK101 has been created on the platform, ac- Response validation. However, CAS needs to be
cessible to a student of another institution by pre- able to create a new student “on demand” on
senting the necessary STORK attributes and iden- Fenix, meaning that it has to be able to invoke an
tity credentials. API developed for this purpose. The API follows a
To allow Academic to grant access to an exter- RESTful architecture and is secured by username
nal eLearning student via STORK without chang- and password for access control and HTTPS. Two
ing the core business logic of the platform, two steps distinct functions are provided by the API:
were required:
Student enrolment: Receives a JSON object
1. Develop the necessary changes for the CAS containing the following parameters: eIdentifier,
server to be able to create and validate SAML givenName, surname, gender, eMail and textRes-
Requests and SAML Responses, respectively; idenceAddress. The function searches for a student
entry that has an IdDocument whose value matches
2. Develop the necessary auxiliary classes and an
the received eIdentifier. If a match is found, the IS-
API on Fenix to allow the creation of a student
TID is returned as a string in the entity body HTTP
on-demand, so that he can be identified by the
field with code “200 OK”, otherwise, the student is
system and logged into a session.
created using Academic domain methods providing
3.2.2 CAS Integration the remaining attributes as parameters. Because
The CAS server does not offer an out-of-the-box no actual value is retrieved from STORK for the
solution that works for authentication through the IdDocument object associated to the Person, the
Security Assertion Markup Language (SAML) as- eIdentifier is stored as the IdDocument value of the
sertions used within the STORK context. Because Person object created for the new eLearning student
of this, it was necessary to develop two different so that it can be identified and retrieved. Finally,
authentication flows: a new ISTID is returned in the HTTP entity body
response with code “201 CREATED”.
The SAML Request flow: This is the web flow NIC lookup: Receives a JSON object contain-
that allows a user to begin the authentication pro- ing the NIC of the student. A domain function is
cess via the STORK infrastructure. This implies called to search and retrieve a Person object pro-
the addition of an option on the CAS login page viding his NIC value. If a match is found, the cor-
that users can select if they want to authenticate us- responding ISTID is returned in the HTTP entity
ing their European eID credentials. Moreover, be- body with code “200 OK”, or an empty string with
cause the S-PEPS needs to know to which country HTTP code “404 NOT FOUND” otherwise.
to redirect the SAML Request, a WAYF page where Once the student has authenticated at the CAS
the user selects his country of origin was added to server and is redirected to the Academic platform,
the CAS user interface. Finally, a controller that a filter intercepts the HTTPS request and looks for
constructs the SAML Request and sends it to the the generated ticket in the parameters. Then, the
S-PEPS by redirecting the user’s browser has also CAS client establishes a secure connection with the
been created. server to validate the retrieved ticket and upon suc-
The SAML Response flow: Is the web flow cessful validation, the client receives the principle
that validates the SAML Response when the user with the ISTID of the user. Now that Academic

8
can identify the authenticated student, a browser
SSO session is established, so that during the va-
lidity of the current session the user doesn’t have
to sign in again to access his personal area on the
platform. In the case of a STORK student, he will
be able to access the contents of eLearning course,
while IST students can access the courses they are
currently enrolled in.

4. The Attribute Provider

The AP has the main purpose of serving student

academic related attributes upon receiving a re-
quest from the STORK infrastructure. Figure 8: Illustration of the overview of all the ele-
4.0.4 Software Architecture ments of the pilot.
The AP has has been developed in a separate mod-
ule that is injected as a dependency on the Aca-
There, the requests follow different paths depend-
demic platform, and is included in the assembled
ing on the country of origin of the user, reaching the
WAR file upon compilation. This tight integration
respective IdP and possibly AP(s), obtaining the re-
into the Academic platform was necessary because
sponse through the reverse path and obtaining the
the students information stored in its database is
assertions.
accessible through its domain level methods. The
AP endpoint is automatically available upon de- 6. Results
ployment of the Fenix platform.
The AP receives requests directly from the PIAP At the time of writing of this document, the pilot
(see section 2.3) via the SOAP web service, being is still ongoing, but cross border tests haven’t been
completely agnostic of the SAML messages and pro- possible yet due to delays in the deployment of the
tocol, however, the attributes in the response have national STORK infrastructure. All the pilots were
to be compliant with the STORK specifications. successfully deployed in a test environment using
a local deployment of all the different components
4.0.5 Implementation of the PEPS model to simulate the whole route
The PIAP is the Portuguese IdM interface be- the SAML messages would go through, as well as
tween the STORK infrastructure and the national authentication and attribute retrieval. Because of
APs. The protocol used for the communications this, no user tests with foreign partners were possi-
is the SOAP web service standard whose interface ble using the infrastructure.
is defined by a Web Services Description Language
(WSDL) file that specifies the format and content 6.1. TADS
types of the request received by the APs and its The TADS server is currently deployed4 and is able
response to the PIAP. The communication model to request some attributes from the national IdM.
is asynchronous, meaning that the APs must re- So for, only attributes that are available on the
spond to the PIAP immediately after receiving a national citizen database is retrievable (e.g: NIC,
request, acknowledging it with a HTTP “200 OK” NIF, givenName, surname, age, gender). The na-
message. After the acknowledge is sent, the request tional APs still aren’t reachable, meaning that the
is processed and once all the attributes have been full chain that a request¡-¿response flow would go
constructed, another web service provided by the through nationally to retrieve attributes from other
PIAP is invoked from the AP, with the response in institutions (e.g:TADS↔PEPS↔FA↔PIAP↔AP)
the request parameters. hasn’t been tested yet. In the test environment de-
ployment of the infrastructure, we were able to suc-
5. System overview cessfully create documents containing simple and
complex attributes.
Now that we have explained all the components of
the academic pilot, we will give a macro view of 6.2. AP
how it all links together. Figure 8 shows the overall The AP was successfully integrated with the na-
components and their interactions. tional IdM, and testing from the national entity
Both the TADS and eLearning may start a managing it successfully retrieved test attributes.
STORK authentication and attribute retrieval flow However, as mentioned above, the PIAP is still be-
by forwarding the SAML Request to the national
PEPS server of the national IdM infrastructure. 4 [Link]

9
ing integrated with SCAP and the national PEPS, [4] A. Jøsang and S. Pope. User centric iden-
and because of this it isn’t possible to test the re- tity management. In AusCERT Asia Pacific
trieval of academic attributes through TADS. Information Technology Security Conference,
page 77, 2005.
6.3. eLearning
The eLearning pilot was also successfully deployed [5] A. Kalja, J. Pold, T. Robal, and U. Vallner.
in a test environment, creating and enrolling a stu- Modernization of the e-government in esto-
dent presenting STORK credentials and attributes nia. In Technology Management in the Energy
to the CAS server and being able to access the Smart World (PICMET), 2011 Proceedings of
STORK101 course on Fenix. For the same reasons PICMET’11:, pages 1–7. IEEE, 2011.
described above and because the deployment of the
national PEPS is still not always available, cross- [6] V. Koulolias, A. Kountzeris, H. Leitold,
border tests weren’t possible so far. B. Zwattendorfer, A. Crespo, and M. Stern.
Stork e-privacy and security. In 5th Interna-
7. Conclusions tional Conference on Network and System Se-
curity, pages 234–238. IEEE, Sept. 2011.
This work proposed and developed software solu-
tions for the Portuguese STORK Academic LSP, [7] H. Leitold and A. Tauber. A systematic
which consisted in the integration of both the de- approach to legal identity management–best
veloped SP (TADS) and the pre-existing Fenix SPs practice austria. In Proceedings of the Infor-
with the STORK infrastructure. The development mation Security Solutions Europe 2011 Con-
of a SP from square one and the integration with the ference, pages 224–234, 2011.
infrastructure of previously existing systems (Fenix [8] T. Martens. Electronic identity management in
and CAS) presented different challenges. estonia between market and state governance.
These challenges allowed for a better understand- Identity in the Information Society, 3(1):213–
ing of the implication of such an infrastructure at an 233, 2010.
European level and the effort required for SPs and
APs to embrace it, as well as the difficulties faced [9] R. McKenzie, M. Crompton, and C. Wal-
into its integration with already existing IdM solu- lis. Use cases for identity management in
tions at a national level. As we were overcoming e-government. IEEE Security & Privacy,
these challenges, useful information was gathered 6(2):51–57, 2008.
for the pilot and its partners.
We succeeded in the implementation of all the [10] G. Moniava, E. Verheul, and L. Schoenmakers.
requirements and created the necessary conditions Extending DigiD to the private sector (DigiD-
for user testing of the national STORK infrastruc- 2). PhD thesis, Masters thesis, Department
ture. It is clear however, that from the gathered of Mathematics and Computing Science, Eind-
experience and information, while achievable, full hoven University of Technology, 2008.
interoperability is still far from being optimal, as [11] T. Rissanen. Electronic identity in finland: Id
usability is still poor from the users perspective and cards vs. bank ids. Identity in the Information
it’s somewhat difficult to teach them the benefits of Society, 3(1):175–194, 2010.
strong authentication, as well as how the STORK
usage flow protects their data from misuse and dis- [12] T. Rössler. Giving an interoperable e-id so-
closure to third parties. lution: Using foreign e-ids in austrian e-
government. Computer Law & Security Re-
References view, 24(5):447–453, 2008.
[1] B. P. Bruegger, D. Hühnlein, and M. Kreutzer. [13] J. Torres, M. Nogueira, and G. Pujolle. A sur-
Towards global eid-interoperability. In vey on identity management for the future net-
BIOSIG, pages 127–140, 2007. work. Communications Surveys & Tutorials,
IEEE, 15(2):787–802, 2013.
[2] R. Dhamija and L. Dusseault. The seven flaws
of identity management: Usability and security [14] B. Zwattendorfer, I. Sumelong, and H. Leitold.
challenges. Security & Privacy, IEEE, 6(2):24– Middleware architecture for cross-border eid.
29, 2008. In 2012 Fourth International Conference on
Computational Aspects of Social Networks
[3] J. Jensen. Federated identity management (CASoN), pages 303–308. IEEE, 2012.
challenges. In Availability, Reliability and
Security (ARES), 2012 Seventh International
Conference on, pages 230–235. IEEE, 2012.

10