EID for authentication in applications/desktop
Using eID for logins: user authentication
In Estonia there are three main ways for logging into a web application:
- User name / password.
- Facebook/Google/Twitter or other social media account.
- eID either as an ID card or a mobile ID
The main advantages of eID over the other two are (a) significantly higher security (b) economizing on amount of work otherwise going into managing usernames/passwords: no need to create / replace lost passwords.
The main disadvantage is inconvenience for a user, who has to use an ID card or a mobile ID.
In most cases it makes sense to implement eID as a more secure alternative to some of the beforementioned ways to login in. For example, one could allow the user to perform less critical tasks without authenticating with eID.
Implementation costs for eID are similar to costs for implementing authentication with social media accounts and are slightly higher than for the username/password system. During actual use the gains achieved stem from (a) minimizing the risk of fraud (b) decreasing the amount of work of the IT department. On the other hand, mobile ID creates a monthly cost due to a need to sign an agreement with the Certification Center. Using an ID card does not necessitate this cost.
For the special case of logging into a desktop application it makes sense to use an ID card primarily in case the organization has a large number of computers managed via a centralized Windows domain and the IT department has a significant burden creating new passwords and replacing the existing ones.
As a concrete example we bring the Case study of logging into the study portal and computers of the Tallinn Uni of Tech: a multi-layered system with the user numbers from a few thousand employees to tens of thousands of students. The chief gains obtained at TTU are improved security and economizing the time of IT support. You may want to take a look at the longer list of applications supporting eID.
A significant percentage of web applications ask the user to log in, meaning that the user authenticates herself, after what the user receives a right to perform certain actions.
As mentioned before, in Estonia the main ways to authenticate the user are (a) user name / password (b) Facebook/Google/Twitter or other social media account (c) eID either as an ID card or a mobile ID.
Employing eID enables a significantly higher level of security than user names/passwords or social media. Equally important is economizing time of IT support by minimizing the need to create usernames and passwords for new users and to send new passwords in case a user loses the password. At the same time, using eID is typically less convenient for the end user than the other means of loggng in.
Related to logging in to web applications is the question of sending passwords to users via a secure channel.
In addition to web systems users regularly log in to desktops of their own computers or computers of the organziation, put to general use. Again, there are two main ways for logging in to a desktop in the Estonian context: (a) user name and password (b) ID-card.
After the system has been logged in, it may be beneficial to send user information to external systems, like the printing service managed by a third party.
For all the authentication systems an important factor is an existence of a central account management system used by different subsystems of the organization.
Logging into a web application
Using eID for authentication is a sensible choice mainly in cases where either security is critical or the number of users is high and the effort to administer the users is significant.
It is often a good idea to implement a combined system where:
- The user must log in via eID to access functionality with higher security requirements.
- Passwords or loggin in via social media is sufficient for less critical functionality.
- Informative functions do not require any authentication.
Implementing authentication with eID is completely different from implementing authentication with mobile ID. We recommend to consider whether to implement both or just one of them. The amount of work required for implementation is roughly similar, but mobile IT requires paying a regular fee for the OSCP service: this can be avoided for ID card in less critical systems.
An important consideration when implementing eID is inconvenience for users and practical restrictions:
- It is inconvenient to search for the ID card and insert it into the card reader.
- Using a mobile phone for authentication is also somewhat inconvenient.
- The ID card cannot be used in phones or most tablets, leaving only mobile ID as an option there.
- Some potential users (foreigners, for example) may not have an ID card or mobile ID.
These aspects may necessitate using other authentication methods in addition to eID.
Logging into a web application with eID is a fairly conventional functionality, yet there are many options and choices for implementation. Hence the actual needs and suitable approaches require careful analysis.
In most cases the implementation will consist of following steps:
- Requirement analysis and choosing the principles of implementation. Time estimate a half day or a full day.
- Ordering and installing server certificates. Time estimate a few hours, plus ca day of waiting for the certificates.
- Implementing authentication with mobile ID (if so decided). Time estimate one day.
- Integration with a web application. Time estimate from a few hours to one day.
Altogether we estimate the implementation to take from a few hours to ca four-five days.
The full guide with examples can be found from here: Authenticating in web applications. Notice that:
- The main bulk of work for authenticating a user with an ID card is performed by a suitably configured web server itself: there is no need for additional programming.
- For authentication with mobile ID the implementor must program herself and/or use provided example programs.
- For ID card it must be decided whether to check the validity of certificates and how exactly (either by using free revocation lists or a paid OCSP service).
- Configuring different web servers (Apache, Ningx, IIS, Oracle etc) for an ID card is significantly different. Apace is probably the most popular choice.
- Once the server has authenticated the user, it will make a text encoding user name, person code etc available to the application. Parsing this text is not completely trivial: non-ascii symbols, old-style certificates and differences in libraries used by the server create a number of different special cases.
- When writing the final application one should estimate the frequency of asking the authentication text by the web server: for some applications it may be a good choice to use ID card for authentication only for creating a session. Session can then be stored in cookies, for example, enabling the user to remove the card from the reader.
Logging into the desktop
ID card is a usable alternative to conventional ways of logging into a desktop: a password or a fingerprint. However, it is not especially popular, since user name and password are, in most cases, easier to use than the ID card.
Implementing authentication based on an ID card is recommended in cases it eliminates a significant amout of regular work from the IT support, primarily the need to create accounts and passwords for new users and to replace lost passwords.
The aspect of higher security is also worth considering, but it is not as important as in, say, web applications: the users normally do not pass their desktop user names / passwords to other people.
In the technological sense, implementing desktop authentication for a single computer is different from implementing the same for a number of centrally managed computers (typically in MS Windows domain). The implementation is also different for Windows, Apple and Linux OS-s.
As a general recommendation it makes sense to consider authentication using an ID card for scenarios with a large amount of computers running Windows and being managed centrally via a Windows domain.
Considering a scenario with a centralized Windows domain we recommend to consider implementing a centralized account management system, enabling users to change their own Windows desktop passwords and other information: either in addition - or as an alternative - to logging into a desktop with an ID card. Logging into the centralized account management would be performed via an ID card or mobile ID. Enabling the users to perform such management operations themselves diminishes the amount of administrative work performed by the IT department.
In addition to self-service the centralized management system makes it possible to connect third-party services like paid printing, etc.
For example, such a system has been implemented in the Tallinn University of Technology.
Logging into the desktop with an ID card can be extended to desktop applications requiring logging in, like the desktop application for family doctors. However, such applications are increasingly rare.
A more widespread additional functionality to consider is using secure private networks (VPN). Logging into the desktop can be extended to logging into a VPN.
In the following we will assume that the end-user computers have been made centrally manageable using the Windows domain and the user accounts have been implemented using Windows Active Directory. The technical guide can be found from the file http://www.sk.ee/upload/files/ID-login_juhend.pdf .
- Requirement analysis and choosing the principles of implementation. Time estimate a day or a few days.
- Implementing the system for automatically obtaining certificates. Time estimate ca two days. We recommend to use a commercial tool by octoX with a cost of a few thousand EUR. The tool enables to configure automatizing the import of certificates and performing required operations in the Windows domain.
- Configuring the Windows domain and policies. Importing root certificates from the SK. Time estimate two days.
- Informing users about the possibility of logging in using an ID card. Time estimate one day.
- Optionally: implementing a self-service system for central account management described above. Time estimate one week.
- Optionally: implementing integration with a dekstop application requiring eID authentication. Time estimate four days.
- Optionally: implementing integration with encrypted VPN. Time estimate one week.
To summarize, the estimated amount of work is expected to remain between one and three/four weeks, depending on the functionality and ambitiousness of the solution.