First lecture of e-Idenity and e-Government EL/LAK Code Camp

1.  i4M Lab
1
ΕΛΛΑΚ Μονάδες Αριστείας (ΜΑ. ΕΛΛΑΚ)
Σχολείο Ανοικτού Κώδικα ΕΛ / ΛΑΚ: e-Identity & e-Government
(Hλεκτρονική ταυτότητα στη Δημόσια Διοίκηση και Τοπική Αυτοδιοίκηση)
UAegean Center of Excellence (CoE) – Open Source Software in Transport
and Shipping
University of the Aegean
Dpt of Financial and Management Engineering & Dpt of Shipping and Transportation Services
Session: I
Stelios Lelis , i4M Lab, UAegean
Harris Papadakis, i4M Lab, UAegean
@ i-nformation M-anagement Lab
i4M Lab

2.  i4M Lab
Ταυτότητα Σεμιναρίου
 Το Πανεπιστήμιο Αιγαίου, στα πλαίσια του έργου Μονάδες Αριστείας
Ελεύθερου Λογισμικού / Λογισμικού Ανοικτού Κώδικα (ΕΛ/ΛΑΚ)1,
διοργανώνει Σχολείο Ανοικτού Κώδικα ΕΛ / ΛΑΚ με θέμα «e-Identity &
e-Government (Hλεκτρονική ταυτότητα στη Δημόσια Διοίκηση και
Τοπική Αυτοδιοίκηση)».
1 Το υποέργο Μονάδες Αριστείας ΕΛ/ΛΑΚ υλοποιείται στο πλαίσιο του έργου «Ηλεκτρονικές Υπηρεσίες για την Ανάπτυξη και
Διάδοση του Ανοιχτού Λογισμικού» του Προγράμματος «Ψηφιακή Σύγκλιση». Το έργο συγχρηματοδοτείται από το ΕΤΠΑ.
2

3.  i4M Lab
Σήμερα 03.11.2015
3
Introductory session: Electronic
Identity: Organization and
Fundamentals, STORK2.0,
Interconnection Supporting Service
16:00 - 20:00 4 ώρες
Στέλιος Λέλης
Χαράλαμπος
Παπαδάκης

4.  i4M Lab
Online tools και άλλα
 Πολλά, θα σας ενημερώσουμε προοδευτικά
 Τώρα, η βασική αναφορά για την ύλη του μαθήματος
 https://openeclass.aegean.gr/courses/OPENSOURCE102/
 ... Και στην επικοινωνία
 seminar e-mailing list: e-identity-iss-community@googlegroups.com
 Ομάδα διδασκαλίας και συντονισμού
 Στέλιος Λέλης
 Χάρης Παπαδάκης
 Πέτρος Καβάσαλης
4

5.  i4M Lab
INTRODUCTORY SESSION: ELECTRONIC
IDENTITY: ORGANIZATION AND FUNDAMENTALS,
STORK2.0, INTERCONNECTION SUPPORTING
SERVICE
Session I
5

6.  i4M Lab
Session I: agenda
 Electronic Government – Electronic Identity: Organization
and Fundamentals
 STORK2.0
 Interconnection Supporting Service
6

7.  i4M Lab
Session I: agenda
 Electronic Government – Electronic Identity: Organization
and Fundamentals
 STORK2.0
 Interconnection Supporting Service
7

8.  i4M Lab
e-Government
8

9.  i4M Lab
electronic Identity
 electronic Identity
 an “Electronic identity” is a means for people to prove electronically that they are who
they say they are and thus gain access to services. The identity allows an entity
(citizen, business, administration) to be distinguished from any other.
 It is the representation of an entity (or group of entities) in the form of one or more
information elements which allow the entity(s) to be uniquely recognized within a
context to the extent that is necessary (for the relevant applications).
 a person’s (digital) identity comprises a set of attributes, and only a subset of these
attributes are necessary to allow the person to be sufficiently recognized within a given
context.
 examples
 TaxisNet, University account, Facebook account, Google account
9

10.  i4M Lab
needs and motives
 Citizens and businesses need to have an electronic presence
 protected from abuse and misuse
 confirming unequivocally who they are in electronic transactions
 with different forms according to their wishes
o e.g. in certain circumstances, a person might wish to present himself as the CEO
of a company and in a separate context as the beneficiary of a health insurance.
 They need to have available descriptions of themselves.
 a citizen filling in an online administrative form, a business offering a service
or preparing a tender, or an administration wishing to share information…
 should all be able to dispense with the time wasting and cost involved in
forever answering the same questions in ever more forms
 the corresponding data should be trusted and considered authentic
10

11.  i4M Lab
main benefits
 Supporting e-services
 Improving security in terms of accountability
 Generating economies of scale
 Increasing administrative efficiency and reducing costs
 Reducing the burden when engaging with the administration
 Limiting possibilities for fraud, identity theft and phishing
 Supporting mutual recognition of documents and certificates in cross-
sector and cross-border situations.
11

12.  i4M Lab
concerns
 Costs and Benefits
 Interoperability
 Privacy
12

13.  i4M Lab
identity management systems
 Identity Management
 The whole process of managing of users identity information
 Identity Management Systems
 A set of functions and capabilities (e.g. administration, management and
maintenance, discovery, communication exchanges, correlation and binding,
policy enforcement, authentication and assertions) used for:
o assurance of identity information (e.g., identifiers, credentials, attributes);
o assurance of the identity of an entity (e.g., users/subscribers, groups, user
devices, organizations, network and service providers, network elements and
objects, and virtual objects)
o enabling business and security applications.
13

14.  i4M Lab
separating identity and service provider
 Identity Provider (IdP)
 Responsible for (a) providing identifiers for users looking to interact with a
system, and (b) asserting to such a system that such an identifier presented
by a user is known to the provider, and (c) possibly providing other
information about the user that is known to the provider
14

15.  i4M Lab
advantages of having separate IdPs
 For the service providers (SP):
 They can focus on products and services, not on identity management
 A higher number of potential users.
 Users are demanding federated services. No more sign-in processes.
 For the identity providers (IdP):
 They are becoming key entities on the Internet
 They can specialize on providing several authentication mechanisms and
privacy policies
 They obtain a lot of information about user activities and user profiles.
15

16.  i4M Lab
adding attribute providers
 Attribute Provider (AP)
 Responsible for (a) providing identity information for users looking to interact
with a system, and (b) asserting to such a system that such information
presented by a user is known to the provider
16

17.  i4M Lab
need to federate identity
 How many different user accounts do you have?
 University, Enterprise, Google, Facebook, Twitter, LinkedIn…
 How many different passwords?
 This is a usual “sign in” process:
 You choose a username, a password and provide additional data
 The account is activated through clicking on a link received by mail
 Now you can access to the service providing your credentials
 Repeat these steps for all the services you want to be part of.
 There is a need to federate and to manage the identity
17

18.  i4M Lab
identity federations
 An identity federation is a collection of organizations that agree to
interoperate under a certain rule set.
 The rule set typically consists of legal frameworks, policies and technical
profiles and standards. It provides the necessary trust and security to
exchange identity information to access services within the federation
 Supported by a set of technologies and processes that let computer systems
dynamically distribute identity information and delegate identity tasks across
security domains.
 Users are distributed among several identity management systems
 There are different IdPs and APs
 The existing IdPs and APs can be based on different technologies internally,
but they must agree on a common language for external communication
18

19.  i4M Lab
an example identity federation
19

20.  i4M Lab
organization and function
20

21.  i4M Lab
organization and function II
8 different steps:
1. The resource is requested to the SP
2. User is redirected to the SSO service
3. User is authenticated by the IdP at the SSO Service
4. Response containing the Authentication Statement
5. The response is forwarded to the assertion consumer service
6. Once the assertions are verified the user is redirected
7. New request to the SP including authorization assertions
8. The user obtains the requested service
21

22.  i4M Lab
a practical example
 Shibolleth
 Shibboleth is among the world's most widely deployed federated
identity solutions, connecting users to applications both within and
between organizations. Every software component of the Shibboleth
system is free and open source.
 https://shibboleth.net/
 Accessing content on Springer web site with a University Account…
http://link.springer.com/chapter/10.1007/3-540-45636-8_4
22

23.  i4M Lab
Session I: agenda
 Electronic Government – Electronic Identity: Organization
and Fundamentals
 STORK2.0
 Interconnection Supporting Service
23

24.  i4M Lab
Ηλεκτρονική Ταυτοποίηση Βασισμένη σε
Χαρακτηριστικά
24
Πολίτης,
Εκπρόσωπος
Εξουσιοδοτήσεις (πχ. Εταιρίας)
Ρόλος (πχ. Δικηγόρος, Ιατρός)
ΑΦΜ, ΑΜΚΑ
Οντότητες Στοιχείο
Ταυτοποίησης
Αναγνωριστικά
Ημερομηνία Γέννησης
Επώνυμο
Όνομα
Αναγνωριστικός Αριθμός
Ιδιότητες, Χαρακτηριστικά
Ακαδημαϊκοί Τίτλοι
Βασικά Χαρακτηριστικά

25.  i4M Lab
Ηλεκτρονική Ταυτοποίηση (Διαδικασίες)
25
Πολίτης,
Εκπρόσωπος
Πάροχος
Υπηρεσιών
Διαδικασίες
Πάροχος
Ταυτοποίησης
Αυθεντικοποίηση
Μεταφορά
Χαρακτηριστικών
Ψηφιακή
Υπογραφή
ΑΣΦΑΛΗΣ ΕΠΙΚΟΙΝΩΝΙΑ ΣΕ ΕΜΠΙΣΤΟ ΠΕΡΙΒΑΛΛΟΝ

26.  i4M Lab
Ηλεκτρονική Ταυτοποίηση (Εμπλεκόμενα
Μέρη)
26
Πολίτης,
Εκπρόσωπος,
Φοιτητής κα.
Οντότητες Πάροχος
Ταυτότητας
Πάροχοι Ιδιοτήτων,
Χαρακτηριστικών (AP)
ΕΡΜΗΣ
Eu eIDs
ΓΓΠΣ (αναμ)
ΕΔΕΤ (αναμ)

27.  i4M Lab
LoA eIDAS
27
Assurance level Elements needed
Low - The electronic identification means shall utilise at least one authentication factor.
- The electronic identification means shall be designed so that it can be assumed to be
used only if under the control of the subject to whom it belongs.
Substantial - The electronic identification means shall utilise at least two authentication factors from
different authentication factor categories.
- The electronic identification means shall be designed so that it can reasonably be
assumed to be used only if under the control of the subject to whom it belongs.
High - The electronic identification means shall utilise at least two authentication factors from
different authentication factor categories and protect the electronic identification means
against duplication and tampering.
- The electronic identification means shall be designed so that it can be reliably protected
by the subject to whom it belongs against use by others.
Electronic identification means characteristics and design
Commission Implementing Regulation (EU) 2015/1502

28.  i4M Lab
Επίπεδα Διασφάλισης Ποιότητας Ηλεκτρονικής
Ταυτοποίησης (eidas QAA)
28
STORK QAA eIDAS
Assurance level
Elements needed
2 Low Χαμηλή αξιοπιστία (πχ. username/password – one
authentication factor )
3 Substantial Σημαντική αξιοπιστία (πχ. ψηφιακά πιστοποιητικά -
two authentication factors )
4 High Υψηλή αξιοπιστία (πχ. έξυπνες κάρτες/usb token –
i.e. dynamic two authentication factor )

29.  i4M Lab
Παροχή Ηλεκτρονικής Υπηρεσίας
29
Αυθεντικοποίηση
Εξου/τηση
Πάροχος
Υπηρεσιών
Πάροχος
Αυθεντικοποίησης
Ρόλος
Ακαδημαϊκοί Τίτλοι
Πάροχοι
Χαρακτηριστικών /
Ιδιοτήτων

30.  i4M Lab
eIDAS – STORK interoperability framework
Commission Implementing Regulation (EU)
2015/1501
30
PEPS
MS A
PEPS
MS BΑυθεντικοποίηση
Εκπρόσωπος
mandate
Πάροχος
Ταυτοποίησης
Πάροχος
Ταυτοποίησης
Πάροχος
Χαρ/στικών
Πάροχος
Χαρ/στικών

31.  i4M Lab
Χώρες συνδεμένες στο STORK2.0
31
Austria
Belguim
Czech
Republic
Estonia
France
Greece
Iceland
Italy
lithuania
luxembourg
Netherlands
Slovenia
England
Turkey
Slovakia
Portugal
Sweden
Schweizland
Spain

32.  i4M Lab
Κύκλος Εμπιστοσύνης
 Κάθε PEPS διαχειρίζεται αρχεία καταγραφής
java keystore
 Δημιουργία σχέσεων εμπιστοσύνης με
τρίτους συμπεριλαμβάνοντας τα
πιστοποιητικά τους (ή και τα πιστοποιητικά
της αντίστοιχης Αρχής Πιστοποίησης (CA
authority)) στο δικό τους αρχείο keystore
 Κάθε PEPS διαχειρίζεται τρία τέτοια αρχεία
keystore δύο εκ των οποίων
επικεντρώνονται στην υλοποίηση του
κύκλου εμπιστοσύνης ενώ το τρίτο
χρησιμοποιείται για την αποθήκευση
κρυπτογραφικού υλικού
32

33.  i4M Lab
STORK packages
 PEPS / VIDP
 SAML engine
 Signature & DTL
 Anonymity
 Version Control
 MS package
 SP package
 AP package
33

34.  i4M Lab
STORK functionality
 StdIDP -standard authentication
 AUB - authentication on behalf of
 PV- Powers Validation
 VIDP - Virtual IDP (for
authentication of Austrian citizens
in portals from other MS)
 XHTMLSign - for authentication
of users in Austrian Portals
 VC - Version Control
 Anonimity (for eAcademia pilot)
 DocSign - Digital signature of pdf
documents (indicate the solution
chosen)
 DTL - Document Transport Layer
 DomSpecAtt - Domain Specific
Attributes (eAcademia Pilot)
 Data aggregation/ multiples
values
34

35.  i4M Lab
eID - Data model (not extented)
35

36.  i4M Lab
eID - Data model Description
36
Field Type Values and comments
eIdentifier String
NC/NC/xxxxxxxxx… NC=NationalityCode, the
first one the country of the eIdentifier, the
second one the destination country.
givenName String
surname String inheritedFamilyName / adoptedFamilyName
inheritatedFamilyName String
adoptedFamilyName String
gender String(1) F (Female) / M (Male)
nationalityCode String(2) ISO 3166-1 alpha-2
maritalStatus String(1)
S (Single) / M (Married) / P (Separated)
D (Divorced) / W (Widowed)
dateOfBirth Date (basic format of ISO 8601) YYYYMMDD / YYYYMM / YYYY
countryCodeOfBirth String(4)
ISO 3166-3. Please note that this code is
equal to ISO3166-1 alpha-2 in the majority
of countries, but includes 4 letter
abbreviations for disappeared countries. E.g.
DDDE for the DDR or YGCS for Yugoslavia.
……

37.  i4M Lab
Academic Attributes
37

38.  i4M Lab
Legal Person Attributes & e-Mandate
38

39.  i4M Lab
Timeline
39
Timeline
Workshop
agreement
17-07-15
1st eIDAS
compliant
CEF eID
version
18-09-15
STORK
ends
30-09-15
eIDAS
MW
Adapter
01-12-15
eIDAS
Proxy
Adapter
01-03-16
eSENS
ends
30-03-16
STORK 2.0
Governance
&
Maintenance
handover
State of play
(Organisatio
n and name)
1
2
STORK 2.0
knowledge
transfer
3
Dissemination
plan
4
Press release
future of
STORK 2.0
6
eIDAS MW
adapter
7
STORK 1.0 phase out
Define technical solution
STORK 2.0 features analysis and
prioritisation
9
Press release
future of
eSENS
eIDAS technically compliant version
go live
8
Knowledge
transfer
13
5
18-09-18
Mandatory
eID
recognition
eIDAS node
with STORK
2.0 features
eIDAS node
with other
features
12
14 15
10
CEF eID
packaged
16
eIDAS proxy
adapter
11

40.  i4M Lab
Ελληνικό Δίκτυο STORK 2.0
40
STORK 2.0
ΓΕΜΗ ΑΙΓΑΙΟΥ ΕΡΜΗΣ
ΕΔΕΤ
World
Bridge
NBG
eProcur
ement
ΔΟΑΤΑΠ
ΓΕΕΘΑ
ΑΣΕΠ
Αρχαιολογικό
Κτηματολόγιο
Παρατηρητήρι
ο Η/Μ
Ακτινοβολιών

41.  i4M Lab
Session I: agenda
 Electronic Government – Electronic Identity: Organization
and Fundamentals
 STORK2.0
 Interconnection Supporting Service
41

42.  i4M Lab
The STORK 2.0 Interconnection Supporting
Service
 STORK 2.0 Supporting Service (SS) is a middle man between the
STORK 2.0 system and any Domain Application does not want to
implement the STORK 2.0 protocol.
 Essentially it translates STORK 2.0 requests back and forth into any
other protocol used by the DA.
 STORK2.0 is free / open source available at JoinUp
https://joinup.ec.europa.eu/node/137745

43.  i4M Lab
The STORK 2.0 Interconnection Supporting
Service
 Up to date, SS provides support for Json-based and Web Service based
communication with DAs
 Its modular design makes it easy to add support for other protocols-
methods.

44.  i4M Lab
JSON vs. STORK2.0 SAML - Request
 Json  STORK2.0 SAML
… x 3 pages

45.  i4M Lab
WebService vs STORK2.0 SAML - Request
STORK2.0 SAML

46.  i4M Lab
WebService support - Response

47.  i4M Lab
Supporting Service Architecture
 The following diagram illustrates how the Supporting Service handles all
STORK 2.0 complexity

48.  i4M Lab
Supporting Service Architecture
 Authentication process flow diagrams using the Supporting
Service

49.  i4M Lab
Supporting Service configuration
 The Supporting Service is a Java EE Web Application. It has been tested in Tomcat
7.0 and can be co-hosted with the Service Provider or in a separate server.
 All the configuration information is available in the file: sp.properties. There are a
number of options to set:
 The list of available C-PEPS for the Supporting Service (country.number with the number
of known C-PEPS and for each country: country<X>.name, country<X>.url)
 Configuration information to identify the Supporting Service as a STORK2.0 service
provider (provider.name, sp.sector, sp.aplication, sp.country).
 The QAA that the Service Provider is accepting (sp.qaalevel).
 Finally, the URLs to communicate with all the required modules:
o speps.url: The URL where the S-PEPS is running.
o sp.return: The URL to return to this SP when STORK finishes the identification and attribute
gathering.
o ds.url: The URL of the Service Provider API to retrieve the requested Attribute List.
o ss.url: The URL of the Service Provider API to send the gathered Attribute Values.
o sr.url: The URL to redirect the user once the Supporting Service has completed its task.

50.  i4M Lab
STORK 2.0 PHP API for the Supporting Service
 The PHP API includes the following files:
 database.sql for creating the two tables required by the PHP API
 index.html to demonstrate how a web site will utilize the PHP API
 private.php to demonstrate how a private page works (in our example
we just check that the user has a valid session and the
$_SESSION["user_logged"] variable is set).
 stork2-common.php contains functions shared among the scripts. For
example how to generate a random token and how to open a database
connection.
 stork2-config.php is the file included by all scripts. It contains all the
configuration information and additional includes that are required.

51.  i4M Lab
STORK 2.0 PHP API for the Supporting Service
Request
 stork2-request.php creates a new token, stores the attributes to request
in the database and redirects the user to the STORK 2.0 Supporting
Service.
 stork2-attributes.php provides a JSON output of the Attribute List.
Accesed by the Supporting Service to retrieve the requested Attribute
List.

52.  i4M Lab
STORK 2.0 PHP API for the Supporting Service
Reply
 stork2-values.php is accessed by STORK2.0 to decodes the JSON
object that contains the response and stores the values in the database.
 stork2-login.php will check the credentials provided by STORK2.0 and
redirect the user to the private section of the service provider or to an
error page accordingly.

53.  i4M Lab
STORK 2.0 PHP API for the Supporting Service
 stork2-specific.php is the file that contains the functions to be implemented
by the service provider in order to define its specific functionality. The
functions are:
 get_attribute_list that returns an array with the attributes to be requested (name
and if it is required).
 assign_user_roles that receives an array of attributes with their values. It must
process this array, start a session and set the proper session variables. Then if
everything was OK it must return TRUE and if NOT it must return FALSE. For
example return FALSE if a required attribute contains no value.
 authenticate_supporting_service is used to authenticate API calls from the
Supporting Service. The two API calls are stork2-attributes.php and stork2-
values.php. Since the service provider and the Supporting Service will be running
on the same network we assume that the communication channel with them can
be trusted (if not we can apply VPN). So a plain username/password
authentication is sufficient. But more authentication methods can be supported if
required (ie. Certificate based authentication).

54.  i4M Lab
Extending the Supporting Service
 The SS has a modular design and care has been taken in order to be easily adapted to specific DA needs. If a
DA requires a specific communication protocol (for example Web Services) then we only need to extend the
following two classes:
1. RetrievePersonalAttributeList, in order to retrieve the Attribute List from the DA
2. SavePersonalAttributeList, in order to save the Attribute Values to the DA.
 The RetrievePersonalAttributeList has only one abstract method that need to be implemented for the DA
specific functionality. The signature of the method is:
protected IPersonalAttributeList retrievePersonalAttributeList(String token)
 For the storage of the Attribute Values the SavePersonalAttributeList class must be extended that contains
only one abstract method: savePersonalAttributeList. The signature of the method is:
protected String savePersonalAttributeList(String token, IPersonalAttributeList pal)

55.  i4M Lab
The STORK2.0 Attribute Provider
 The STORK2.0 Attribute Provider (AP) is the system providing Attribute
Information
 APs come from different domains (e.g. Academic, Business, Health) and
provide associated attributes (e.g. Academic AP provides ‘isStudent’,
‘hasDegree’ etc.)
 Multiple APs are connecting to the STORK2.0 infrastructure through the
PEPSes

56.  i4M Lab
The Demo AP
 STORK2.0 provides a free/open source DemoAP
 DemoAP allows organizations to quickly deploy their own APs
 There are more than 20 APs in several European Countries based on the
DemoAP
 DemoAP – STORK2.0 Communication
 STORK2.0 SAML protocol
 An Interconnection Supporting Service for APs?

57.  i4M Lab
Example AP – University of the Aegean
 An adaptation of DemoAP
 Deploys both
 Identity Linking with Shared Identifiers (for quick attribute retrieval)
 Connection with UAegean LDAP
 Retrieves Attribute Information from several Systems of the University
(Data Bases)

58.  i4M Lab
Thank You
 Λέλης Στέλιος
 Χάρης Παπαδάκης
 Αύριο, 04 Νοεμβρίου 2015 @ 16:00
 «STORK2.0 Interconnection Supporting Service Architecture, Aplication
Protocol Interfaces, hands-on experience»
58