EMREX Architecture
Versjon 21.1.2015
EMREX Architecture
Page 1
Studentweb (NO)
SMP
1. CSC  + URL_NCP?
NCP (FI)
2. request + return URL (sig FSAT, enc CSC)
CSC
FSAT
3. Get ELMO
4. ELMO (sig CSC, enc FSAT)
5. Put ELMO
FS
EMREG
Id
Type
Name
URL_NCP
Pubkey 
1
NCP
FSAT
http://fsat.no/
ssh-rsa AAAAB3Xgfe3vde...
2
NCP
CSC
http://virtawstesti...
ssh-rsa AAAAmder3tgfew...
Overall design
Student Mobility Plugin (SMP)
This is a common plugin that all applications using EMREX must use. It is not a graphical plugin, but a
library that offers common functionality:







Fetch a list of NCP’s and present as either JSON or a generic HTML table/list
Creating a request to the NCP and encrypting it
Forwarding request to the correct NCP
Returning signed and encrypted data from NCP
Validating reply from NCP
Checking that the student is valid
Presenting the results both as raw data and in a generic HTML table/list
The SMP is mostly used by clients that want to fetch results, but also contains functionality that the
NCP can use. The common code of the SMP is not a graphical component but will have functions that
can present some HTML that websites can use and for example plug in their own style sheets. In
addition, the sites using the SMP will off course use their own graphical components around the SMP.
The SMP will have its own public/private key-pair that is will use for encrypting/decrypting messages.
When the request is sent from the SMP to the NCP, the request will contain the public key of the
SMP so that the NCP can use this key to encrypt the reply. This way, EMREG does not need to contain
every single client that wishes to fetch results, just a list of NCPs.
EMREX Architecture
Page 2
Input for the SMP:

Student data (used for validation)
Output from the SMP:


Requests for NCPs
Results in a common, agreed upon, format
National Contact Point (NCP)
This is where the request for results will come. This NCP can be tailored to the specific country, and
must fulfill certain tasks / interfaces, such as:






Receiving request from an SMP
Secure login, for instance, using the country’s ID-federation
Provide functionality that enables the student to search and fetch results from one or more
institutions
Functionality for filtering the results that is supposed to be returned
Serialize the results in the common, agreed upon, format
Create a reply for the requesting SMP
Some of the tasks the NCP must fulfill are common and can therefore be implemented in the SMP.
The NCP can then use the SMP as a library for these common tasks. This way, the data transfer is
potentially less error prone and it will be easier to implement an NCP.
EMREG
EMREG is the central registry of all available NCPs. This is the only central part of the EMREX system.
EMREG has 3 main parts:
-
-
-
A database that contains the EMREG data
o NCP-ID
o Name
o URL
o Public key
o Available (Should the database poll all URLs on a regular basis to check?)
o Additional data (statistics, persons responsible of NCP…)
A web service that exposes the database
o NCP-list: Return a list of all available NCP’s
o NCP-info: Return info on a given NCP
A website for administering each countries NCP data. Alternatively, the website is used to
apply for an entry in the registry
When an SMP wants to contact an NCP, it contacts EMREG through the web service to get the URL
and public key of the selected NCP.
EMREX Architecture
Page 3
There are a couple of crucial aspects of EMREG:
1. The NCP must be a valid NCP, so there must be a limited number of people who wil have
access to to add an NCP to the registry
2. The URL must be a proper URL. It is very important that the URL of the NCP does not point to
a fake site, for example a diploma mill
3. The Public key must be verified. There must be no doubt that the public key connected to the
NCP is valid and trusted.
Administration EMREG
A way to administer the database is that the database is administered by the organization that hosts
the database and the website is only used to apply for an entry in the EMREG database.
The organization will then also be responsible for creating and distributing the public/private keys to
the different institutions.
In this solution, all keys are handled by one entity. There will be more work for that organization, but
it might be easier to ensure the integrity of the data in EMREG.
Security
Security and trust is vital for EMREX:
1. There must be no doubt that the request to an NCP comes from a valid and trusted SMP
2. There must be no doubt that the NCP that is asked is valid and trusted
3. There must be no doubt that the results returned from the NCP belongs to the correct
student and has not been tampered with on the way
The best way to ensure (1) is that the Certificate the SMP use comes from a trusted partner (for
instance Terena).
The best way to ensure (2) is that EMREG is a trusted site and that all public keys and URLs in the
EMREG database are quality assured and validated.
To ensure (3), we need a combination of trusted certificates, a two-stage login (both SMP and NCP)
and an algorithm of checking that the student in the request (ST1) is the same student as the one in
the reply (ST2). This can be checked by an algorithm in the SMP. Since names can be written in
different ways, we cannot do a complete match on names, so a fuzzy match is suggested. Suggested
algorithm:
(Bday of ST1 = Bday of ST2) AND (Sex of ST1 = Sex of ST2) AND (85% fuzzy match on name).
If this algorithm is not matched there are two ways of dealing with this:
1. Refuse the transfer
2. Flag the data as “needs manual check”
EMREX Architecture
Page 4
A practical case
The following case will describe the components and operations based on the sketch above.
Student Jorma has come to from University of Helsinki to Norway to study at the University of Oslo.
After being registered as a student in Oslo, he wants to fetch to fetch his results from the University
of Helsinki.
Step 1: University of Oslo
-
Jorma logs into Studentweb, using FEIDE (Norwegian ID Federation).
Jorma clicks “Fetch results”
The SMP, that is installed in Studentweb, fetch the list of available NCP (fetched from EMREG)
and presents them to Jorma in Studentweb
Jorma selects the correct NCP (Finland) and clicks the button for fetching results
Step 2: Forwarding to Finnish NCP
-
-
SCP creates a POST-request containing the following:
o A unique session ID, encrypted with the public key of the Finnish NCP (fetched from
EMREG)
o A representation of Jorma (name, D.O.B., sex)
o The callback-URL that the Finnish NCP should reply to (fetched from EMREG)
o The name of the Norwegian NCP (fetched from EMREG)
The SMP sends this POST-request to the URL of the Finnish NCP (fetched from EMREG)
Step 3: The Finnish NCP
-
-
-
The first thing Jorma has to do is to log in using Haka
The Finnish NCP asks the Finnish SMP if this Jorma is the same Jorma that logged in in
Norway. Since both Haka and Feide has the Name, sex and D.O.B. of Jorma, the SMP can
match these two and see if it’s the same student. Since names can be spelled differently in
different countries the algorithm looks something like this:
o D.O.B. matches
o Sex matches
o Name has a fuzzy match of more than 50%
The Finnish NCP is satisfied that the Jorma that logged in in Norway is the same Jorma that
logged in in Finland and therefore guides Jorma through the process of finding his results.
This process cannot be standardized as different countries have different systems, so each
country must implement this part
Jorma is presented with his results
Jorma clicks “Return these results”
The Finnish NCP serialize the results to a standard format (for example ELMO)
The Finnish NCP returns the following to the Norwegian NCP (URL given in the original
request):
o Encrypted ELMO with the Norwegian NCP public key (fetched from EMREG)
o The same session ID as from the request, first decrypted and then encrypted with the
Norwegian NCP public key (fetched from EMREG)
EMREX Architecture
Page 5
Step 4: The Norwegian NCP
-
The Norwegian NCP receives the encrypted data from the Finnish NCP
The NCP checks that the session id is the same id as from Step 2 and aborts if it is not
The NCP de serialize the ELMO and presents the results to Jorma
Jorma clicks “Transfer results”
The NCP stores the results in the FS-database
EMREX Architecture
Page 6