 Alright, the next talk is by Cornelius and it's on enrolling 2FA to thousands of users using privacy, privacy idea. So, okay, thanks a lot. So we already can skip the first slide. So I assume who of you does not know what two factor authentication is or who of you, yeah, does not know it? Okay, I will shortly tell something about this. And who of you does probably know privacy idea? Okay, roughly the same number of guys. Fine. So my name is Cornelius Ködel and I've been into two factor authentication since 2005 and this started with smart cards. Short introduction actually to factor authentication is something to increase logon security. The user has to authenticate with something he knows and usually with something he has as a second factor. Some make us believe he could also authenticate with something he is, but this might be a topic for another talk. You can reach me via Twitter via email on something like this. Yeah, and in 2014 we started the project privacy idea. So enrolling two factor authentication for several thousand users. Let's take a look at some challenges here. For example, a city administration wants to provide two factor authentication to their citizens. So that's probably not the inhabitants because not all children and not all old people will do two factor authentication to communicate with the city administration. But still, this is a lot of users and a big number and it will contain some difficulties because actually the citizens do what they want and they don't come to my office. Or electricity provider is thinking about adding two factor authentication for their customers, for their end customers. And an electricity provider might even cover a larger area than only a city and thus may have a bigger user number. Or finally, a university thinks about or is planning to enroll two factor authentication to their users, to their students, even to their students. Well, this is only maybe 30,000 users, but still quite a number. And actually a university with students, you can see it on this picture, they all look very happy since they just graduated. This means now they are not my users anymore. This year I will have 5,000 users less, but I will get new users. So dealing with larger numbers is a bit difficult. Actually, users will not come to the administrator's desk. Users might be unknown. Users are, I call it dislocated, they are maybe located around the globe. And probably users, maybe not in the university, but probably such users are not very tech-heavy. And also users should not copy, so it's always the question, how do you think about two factor authentication? Maybe you know the Google Authenticator. This also implies another problem because enrolling a Google Authenticator actually unveils the secret key for your authentication. So we will take a look at privacy idea, how privacy idea can help you to cope with the problems of these large user numbers. What is privacy idea? Privacy idea is an open source project that manages the authentication devices for the users. And as such it is located in your network, somewhere you have your users in an LDAP source, in a SQL database, and then you have installed privacy idea server which reads the user information and you can connect different applications to add two factor authentication to these applications. For example, in the university when the students log into some system where they can manage their grades. Privacy idea also provides a lot of different authentication objects, different token types. We have the classical key fob tokens, we have OTP cards, we have virtual tokens like we can send SMS and we can send emails. Of course all these token types provide a different level of security, but it is always a trade-off of usability, of availability for the users and of security of course. We support the Ubiqui, probably you do not want to enroll 30,000 Ubiquis to users. Well, I know someone who would like to enroll 30,000 Ubiquis to the users, but probably not the administration. We support the U2F protocol and a lot of other things. But in the end, if we think of these large numbers, it is all about automation. We have some installations, typical installations in the hospital where 100 doctors are using a two factor authentication. There is no problem, the administrator says, oh, I asked the doctors, they should come around, they come to my desk and I will give them their token and I will explain it to them and everything is fine. This is a workflow that will not work for 30,000 students. So you have to think about how can I automate things. And luckily, Privacy Idea provides a lot of possibilities to automate things. This is basically the structure of Privacy Idea. We have a database level underneath, everything is stored in a SQL database. We have a library level and we have a REST API, Privacy Idea acts as a web service. And on top of this, we also have some user interface, a web interface where we can click colored buttons. But the important thing is that we can automate processes on these levels. Of course, we could automate things on the database level. Well, if you are happy with writing SQL statements, then you can do this. We can also automate things on the library level, which means Privacy Idea is written in Python and you can write scripts to directly access the Python calls which create tokens, which delete tokens, which manage tokens. And you can do this without even talking to the web server and thus without producing load on the web server. The most interesting part is probably the REST API. And then we have within the system a concept or a solution of an event handler framework. I already talked a bit about the library. Actually, it might look like this. Here you can see, here's a Python call enable token that simply would enable a token and the same way we have a call disable token or we have a call remove token to delete a token. You can use this in your Python scripts. More interesting is the REST API. This basically looks like this. So we have calls to initialize the token to check the validity of a token and the interesting thing is that everything within Privacy Idea is a REST API. That means that you will not find any function within the web interface that is not accessible via a REST API. And this is quite nice because this is actually used, it's a bit dark. This is actually used in a big scale in the city administration. You can develop your own small application, for example, to enroll tokens. They use the token init API and so they can adapt everything to their needs that an employee is able to do only this, what he needs to do and to maybe even trigger several aspects at the moment with only one button or with one command which in the back end triggers several REST API calls. The even more interesting thing is the event handler. This was added to Privacy Idea roughly one year ago and we should take a short look at how a call is processed in Privacy Idea. We have a pre-policy where some conditions are checked. If something fails, if a user has not the necessary rights and exception is raised then actually the request is processed and then we have post-policy and then we get the response and we get the response. But in addition, now you can define additional event handlers which trigger really additional actions. How does an event handler look like? What ingredients does such an event handler have? The event handler defines to which events it is connected, for example to the event initialization of a token. Let's say assignment of a token. Imagine we are enrolling keyfog tokens, assignment of a token. Then it defines which handler module should be used. We have currently four handler modules, notification, token, federation and script, and each do some different things. For example, even the script handler can call any arbitrary script on your machine to do many evil things. We have conditions and we have finally the actions with options. So an example could be you are enrolling or you are assigning a hardware keyfog token but you define an event that a token handler will be called and in addition, for example, automatically an SMS token is generated. So this way you could, if the help desk user assigns a token to a user, create additional tokens or create additional information for tokens. I have a weird example here. We also have a paper token. For example, if a help desk user creates a paper token for a user, this token can be automatically disabled so that the help desk user will not misuse this token or impersonate the user. But this paper token will be enabled if the user authenticates with the registration code and the user gets notified if the registration code is used because maybe the registration code was stolen by an attacker so that the user can know that something went wrong. And in addition to support any kind of workflow that you can imagine, we can also set any arbitrary attributes for a token device so that the help desk user, for example, can search for this arbitrary attribute. For example, the university is enrolling ubiquies to the employees and when they enroll the ubiquie or when they assign the ubiquie, they set an arbitrary attribute prepare for shipping because they know that they have to send via snail mail the ubiquie to the user. And so they can find in the database which ubiquies still need to be shipped and which are already shipped. And as I already pointed out, you can run external scripts. And the university, we are again back at the university, the university uses the API calls to actually add a registration code in the welcome letter when a new student arrives at the university. He gets the letter with all his information and in addition the welcome letter with the registration code. But I'm sorry, the time is up. You are quiet. Successful authentication is a matter of automation. Thank you. Thanks for the news.