e-idenity-and-e-government_elak-code-camp-lecture_i
TRANSCRIPT
i4M Lab1
ΕΛΛΑΚ Μονάδες Αριστείας (ΜΑ. ΕΛΛΑΚ)Σχολείο Ανοικτού Κώδικα ΕΛ / ΛΑΚ: 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, UAegeanHarris Papadakis, i4M Lab, UAegean
@ i-nformation M-anagement Labi4M Lab
i4M Lab
Ταυτότητα Σεμιναρίου
Το Πανεπιστήμιο Αιγαίου, στα πλαίσια του έργου Μονάδες Αριστείας Ελεύθερου Λογισμικού / Λογισμικού Ανοικτού Κώδικα (ΕΛ/ΛΑΚ)1, διοργανώνει Σχολείο Ανοικτού Κώδικα ΕΛ / ΛΑΚ με θέμα «e-Identity & e-Government (Hλεκτρονική ταυτότητα στη Δημόσια Διοίκηση και Τοπική Αυτοδιοίκηση)».
1 Το υποέργο Μονάδες Αριστείας ΕΛ/ΛΑΚ υλοποιείται στο πλαίσιο του έργου «Ηλεκτρονικές Υπηρεσίες για την Ανάπτυξη και Διάδοση του Ανοιχτού Λογισμικού» του Προγράμματος «Ψηφιακή Σύγκλιση». Το έργο συγχρηματοδοτείται από το ΕΤΠΑ.
2
i4M Lab
Σήμερα 03.11.2015
3
Introductory session: Electronic Identity: Organization and Fundamentals, STORK2.0, Interconnection Supporting Service
16:00 - 20:00 4 ώρες Στέλιος ΛέληςΧαράλαμπος Παπαδάκης
i4M Lab
Online tools και άλλα
Πολλά, θα σας ενημερώσουμε προοδευτικά Τώρα, η βασική αναφορά για την ύλη του μαθήματος
https://openeclass.aegean.gr/courses/OPENSOURCE102/ ... Και στην επικοινωνία
seminar e-mailing list: [email protected]
Ομάδα διδασκαλίας και συντονισμού Στέλιος Λέλης Χάρης Παπαδάκης Πέτρος Καβάσαλης
4
i4M Lab
INTRODUCTORY SESSION: ELECTRONIC IDENTITY: ORGANIZATION AND FUNDAMENTALS, STORK2.0, INTERCONNECTION SUPPORTING SERVICE
Session I
5
i4M Lab
Session I: agenda
Electronic Government – Electronic Identity: Organization and Fundamentals
STORK2.0
Interconnection Supporting Service
6
i4M Lab
Session I: agenda
Electronic Government – Electronic Identity: Organization and Fundamentals
STORK2.0
Interconnection Supporting Service
7
i4M Lab
e-Government
8
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
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
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
i4M Lab
concerns
Costs and Benefits Interoperability Privacy
12
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
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
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
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
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
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
i4M Lab
an example identity federation
19
i4M Lab
organization and function
20
i4M Lab
organization and function II
8 different steps:1. The resource is requested to the SP2. User is redirected to the SSO service3. User is authenticated by the IdP at the SSO Service4. Response containing the Authentication Statement5. The response is forwarded to the assertion consumer service6. Once the assertions are verified the user is redirected7. New request to the SP including authorization assertions8. The user obtains the requested service
21
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
i4M Lab
Session I: agenda
Electronic Government – Electronic Identity: Organization and Fundamentals
STORK2.0
Interconnection Supporting Service
23
i4M Lab
Ηλεκτρονική Ταυτοποίηση Βασισμένη σε Χαρακτηριστικά
24
Πολίτης, Εκπρόσωπος
Εξουσιοδοτήσεις (πχ. Εταιρίας)
Ρόλος (πχ. Δικηγόρος, Ιατρός)
ΑΦΜ, ΑΜΚΑ
Οντότητες Στοιχείο Ταυτοποίησης
Αναγνωριστικά
Ημερομηνία Γέννησης
Επώνυμο
Όνομα
Αναγνωριστικός Αριθμός
Ιδιότητες, Χαρακτηριστικά
Ακαδημαϊκοί Τίτλοι
Βασικά Χαρακτηριστικά
i4M Lab
Ηλεκτρονική Ταυτοποίηση (Διαδικασίες)
25
Πολίτης, Εκπρόσωπος
ΠάροχοςΥπηρεσιών
Διαδικασίες
Πάροχος Ταυτοποίησης
Αυθεντικοποίηση
Μεταφορά Χαρακτηριστικών
Ψηφιακή Υπογραφή
ΑΣΦΑΛΗΣ ΕΠΙΚΟΙΝΩΝΙΑ ΣΕ ΕΜΠΙΣΤΟ ΠΕΡΙΒΑΛΛΟΝ
i4M Lab
Ηλεκτρονική Ταυτοποίηση (Εμπλεκόμενα Μέρη)
26
Πολίτης, Εκπρόσωπος, Φοιτητής κα.
Οντότητες Πάροχος Ταυτότητας
Πάροχοι Ιδιοτήτων, Χαρακτηριστικών (AP)
ΕΡΜΗΣEu eIDs
ΓΓΠΣ (αναμ) ΕΔΕΤ (αναμ)
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 designCommission Implementing Regulation (EU) 2015/1502
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 )
i4M Lab
Παροχή Ηλεκτρονικής Υπηρεσίας
29
Αυθεντικοποίηση
Εξου/τηση
Πάροχος Υπηρεσιών
Πάροχος Αυθεντικοποίησης
Ρόλος
Ακαδημαϊκοί Τίτλοι
Πάροχοι Χαρακτηριστικών /
Ιδιοτήτων
i4M Lab
eIDAS – STORK interoperability framework Commission Implementing Regulation (EU) 2015/1501
30
PEPS MS A
PEPS MS B
Αυθεντικοποίηση
Εκπρόσωπος
mandate
Πάροχος Ταυτοποίησης
Πάροχος Ταυτοποίησης
Πάροχος Χαρ/στικών
Πάροχος Χαρ/στικών
i4M Lab
Χώρες συνδεμένες στο STORK2.0
31
Austria BelguimCzech RepublicEstonia FranceGreeceIcelandItalylithuania
luxembourgNetherlandsSloveniaEnglandTurkeySlovakia PortugalSwedenSchweizlandSpain
i4M Lab
Κύκλος Εμπιστοσύνης
Κάθε PEPS διαχειρίζεται αρχεία καταγραφής java keystore
Δημιουργία σχέσεων εμπιστοσύνης με τρίτους συμπεριλαμβάνοντας τα πιστοποιητικά τους (ή και τα πιστοποιητικά της αντίστοιχης Αρχής Πιστοποίησης (CA authority)) στο δικό τους αρχείο keystore
Κάθε PEPS διαχειρίζεται τρία τέτοια αρχεία keystore δύο εκ των οποίων επικεντρώνονται στην υλοποίηση του κύκλου εμπιστοσύνης ενώ το τρίτο χρησιμοποιείται για την αποθήκευση κρυπτογραφικού υλικού
32
i4M Lab
STORK packages
PEPS / VIDP SAML engine Signature & DTL Anonymity Version Control
MS package SP package AP package
33
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
i4M Lab
eID - Data model (not extented)
35
i4M Lab
eID - Data model Description
36
Field Type Values and comments
eIdentifier StringNC/NC/xxxxxxxxx… NC=NationalityCode, the first one the country of the eIdentifier, the second one the destination country.
givenName String surname String inheritedFamilyName / adoptedFamilyNameinheritatedFamilyName 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.
……
i4M Lab
Academic Attributes
37
i4M Lab
Legal Person Attributes & e-Mandate
38
i4M Lab
Timeline
39
Timeline
Workshop agreement
17-07-15
1st eIDAScompliantCEF eID version
18-09-15
STORK ends
30-09-15
eIDASMW
Adapter
01-12-15
eIDASProxy
Adapter
01-03-16
eSENSends
30-03-16
STORK 2.0 Governance
& Maintenance
handover
State of play(Organisation 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
MandatoryeID
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
i4M Lab
Ελληνικό Δίκτυο STORK 2.0
40
STORK 2.0
ΓΕΜΗ ΑΙΓΑΙΟΥ ΕΡΜΗΣ
ΕΔΕΤ
WorldBridge
NBG
eProcurement
ΔΟΑΤΑΠ
ΓΕΕΘΑ
ΑΣΕΠ
Αρχαιολογικό Κτηματολόγιο
Παρατηρητήριο Η/Μ
Ακτινοβολιών
i4M Lab
Session I: agenda
Electronic Government – Electronic Identity: Organization and Fundamentals
STORK2.0
Interconnection Supporting Service
41
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
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.
i4M Lab
JSON vs. STORK2.0 SAML - Request
Json STORK2.0 SAML
… x 3 pages
i4M Lab
WebService vs STORK2.0 SAML - RequestSTORK2.0 SAML
i4M Lab
WebService support - Response
i4M Lab
Supporting Service Architecture
The following diagram illustrates how the Supporting Service handles all STORK 2.0 complexity
i4M Lab
Supporting Service Architecture
Authentication process flow diagrams using the Supporting Service
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.
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.
i4M Lab
STORK 2.0 PHP API for the Supporting ServiceRequest
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.
i4M Lab
STORK 2.0 PHP API for the Supporting ServiceReply
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.
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).
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 DA2. 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)
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
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?
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)
i4M Lab
Thank You
Λέλης Στέλιος Χάρης Παπαδάκης
Αύριο, 04 Νοεμβρίου 2015 @ 16:00 «STORK2.0 Interconnection Supporting Service Architecture, Aplication
Protocol Interfaces, hands-on experience»
58