 Thank you for being here. Thanks to the organizers for managing this room. I'm glad you did the work. I'm talking about authorized entities directory. Authorized entities is the main objective. The name fits the objectives quite well. It's me, I'm doing stuff. So what are the main objectives? This catalog is what you can read about every identity and access management. So everybody, every product, website, you can read those objectives. So no difference. But I want to clarify why things are designed like they are. A couple of years ago, actually six years ago, I just set up a small, LDA-based directory service for a customer in a highly secure, separate data center environment. And it was really deliberately separated from the rest of their world because they had to achieve more strict legal requirements. So they have to match more strict requirements. And then the IT security department guys came and they wrote a report, oh, everything's fine, but there are some low-hanging fruits you should also try to solve. And one of these low-hanging fruits was user accounts should only be added to systems where they have to be added. And this was a very simple open LDA-based directory service. So like with most installation of this kind, every system could see every user and every group. So I scratched my head because this particular customer, it was okay for this separate environment. But this particular customer is running data centers with thousands of machines. And then they said, oh, Michael, LDA user-based management, you can do that and we need that for the rest of the data center also. But the rest of the data center, they have very different roles like developers accessing test machines which are spawned for only a few weeks or something and they have highly secured systems where they do credit card processing or where the account passwords are stored of their customers' accounts. And so I was scratching my head how to accommodate this wide range of different systems with a single directory service. And then, okay, then you remember, okay, this standard set of requirements. Need to know principle, least privilege principle, separation of duties. If you look at all these different roles and people acting in a very agile manner, they are very much into DevOps and you have around, they have 300 or 400 users acting like this, very agile in various teams. Then I scratch my head saying, okay, I have to implement a delegation model and that's not really new, you know, but I have to delegate a delegation module where they can act in a very agile manner. And I didn't want to implement a delegation model based, for example, on organizational structure or something like this because this doesn't work. It's also always a project structure and they have temporary structures, temporary projects, you know, so things are changing all the time. So you have to achieve, to provide a solution for that. Then, of course, if everything is changing all the time, you know, you might want to look afterwards, oh, why did somebody did that? And you have to check whether people are complying to the security requirements the IT security department wrote down. So this led to some paradigms, some technical requirements, some more concrete requirements. I stripped this down a lot, some more, you know, you can see on the front page of the project, but what really is important to me is that things should not be right, access control should not be assigned implicitly. It should be always done by somebody knowing what he's doing. So this is very important, you know, so not by somebody, some team lead in an organizational structure saying, yeah, my employee has to do this and he doesn't know what he's acknowledging, you know, so always have people in charge to really know what they are doing. And of course, I mean, this is a trivial paradigm, you know, secure authorization requires secure authentication. So there's no anonymous access at all and everything, everything, user accounts and machines have to individually be authenticated. And I also, I really hate super mighty proxy roads. We heard in the last talk about loosely coupled systems, syncing data and for this data synchronization, it's good to have this data synchronization, but the requirement then is that you have super mighty credentials for the target system to be synced, you know, so you have system accounts which have domain administrator rights in active directory or something like this, you know, and I try to avoid this as much as possible. It's not always possible, but I try to avoid it. And also, this system strictly distinguished between persons and their multiple accounts. So a person is not an account, a person will never get a password, but the accounts which are connected to these persons will get a password. And you should avoid to directly derive access rights from the organizational structure because organizational structure is going to change nearly every four or five times a year, you know, so you cannot, you cannot rely on that. One of my customers, he said, he made a joke, a project lead, he made a joke, he said, oh, I take our department name as password because nobody can memorize them and they are changing as often as I have to change my password according to the password policy. Yes, okay, so role separation acting on different systems is really implemented by different user accounts which is somewhat inconvenient for the users, of course, for the human beings, but this is the only chance to implement different security policies for different roles. So, and of course, I mean, this is also trivial, you have to provide persistent IDs which never change over the lifetime, which never change, not only over the lifetime of something which never change and which are never going to be reused. Yeah, this is also trivial, but I always have to tell this to my customers, you know, so strange enough. So, there's a pretty straightforward role model and the super high admins are the AI admins, they can manage the idea system itself, that's their task. There are also the system administrator managing the system but also the initial data, especially they maintain zones and zones are just areas of delegated administration. They set up zones and delegate them to other so-called zone admins. The zone admins are the guys who are really doing the daily data maintenance work. Those, the zone admins are the most important administrative role for the daily work because they are supposed to know about the systems. They are supposed to know, oh, if I put a user in this group, it has this impact on these systems. Yeah, and this is not trivial because in reality, it's often like this, that somebody says, ah, I have to access this system and then somebody says, yeah, you have to ask this guy to put you in some weird group and nobody knows what this group is really all about and what impact a group membership has to all the systems. And then, at one time, you disable the group and then nothing works anymore. So to emphasize it, a zone is an area of delegation but you have to chop up your environment, your infrastructure in small manageable areas and assign the zone admin role to people who really know what's in this bucket. You know, an IEA admin just creates a zone, this is an empty bucket and the zone admins, actually, they start to fill up the zone. They put the semantics inside. Okay, and of course, there are companion auditors roles which can read at the global level or at the zone level. So there's another rule which is called setup admin and setup admin is a role somebody who is allowed to set up and administer a service or a host within a cluster, mainly, you know, within a service group. We come to that later. So basically, those guys are the guys, oh, we need another host instance in this cluster, they will set up the virtual machine, they will run the configuration management code or program the DevOps code, whatever you do with AnsiblePuppet or something else. So, and normal users, they can just read their own entries and see member of groups where there are also members of. Okay, so this is the system architecture. Mainly, we have an admin workstation here. We have custom tools, the official API of maintaining data in IEDA is held up because I didn't want to invent another web API stuff with security controls in place. So I have everything there and the access control here in the back end is implementing all the restrictions. So all the access rights and all the constraints. So therefore, I could also use my very generic web UI as an administrative interface for adding users, maintaining groups, things like that, all this data. And there's a special password set, service application where users can anonymously trigger a password reset and there's a two-step process also getting the zone admin involved to reset the password. So, and then guys working here are using the usual SSH client to administrate their Linux servers, Unix servers, whatever. You know, this is just an example of SSD and ZoodoElder being used. And those integrated systems, SSH servers with shell access, database servers or web applications or something, they all go to read-only consumer replicas. So there's a two-tire architecture and this red line is very important to me because the systems in your data center do not access the writable provider. So there's an additional boundary, security boundary so that if something goes wrong here you cannot change data here. LDAP is a hierarchical database, you know. So there's a directory information tree. This is not as important as it looks like because the access control is not based on hierarchical data. So this hierarchy is just for, yeah, because people like it. I could have flattened this completely, but people tend to, yeah, if they have a zone they like to have a tree, a sub-tree with this zone. That's the whole point of it. There's no technical requirement for this. It's just like putting files in a folder. So at the first level there are the zones. There are some special zones with completely public data. All authenticated users can read this. There's a zone for administrating the system itself. Usually there's also kind of a zone where you put organizational data in there, person objects and departments or locations also. So, and then you have any arbitrary zone. And this zone has two special, this is since hard coded, but there are groups defined which act as zone admins and groups which act as zone auditors. Again, also this relationship does not have to be hierarchical. So, and then you have user objects, you have group objects, you have service groups and you have Zoodoo's rules. And then within service groups you have hosts and server services. You can also have tool users which are also services. And because I wanted to point out system management you can even tie the network configuration to the host object. So, this is the complete entity relationship diagram. As you can see, you can see nothing. So, I have a more friendly version of it. And this is the core of the authorization. And so, I usually start here. Service groups are really just clustered services. I could have also caused this service because it's just it models a clustered service. And what you basically are doing is you group your service instances, maybe a cluster of a certain web application or a bunch of hosts which have the same security policy. You group them and then you assign the certain roles, the certain access rights by setting links to groups. And those links also affect the open LDAP access control rules. So, for example, setting the link IA visible groups to a group makes this group object and the members therein visible to all the instances here. So, these instances are authenticating and they are then authorized by the open LDAP ACLs. They follow this link. They work their way through these links. And so, this service or a host gets authorized to seek groups and members. So, it's a little bit different than what other implementations are doing, not the system is filtering which uses groups. It grabs from the directory. The directory has a rough filtering by setting this visible relationship. And this also applies to, for example, the visibility of Zudo's rules. And there are other links. For example, this link is pointing to groups just to accommodate what Zudo LDAP or Zudo over SSSD is requiring. Okay. Yeah, and of course you have network devices. And, okay, and the setup admins, they are allowed to add those entries and those entries. And they are allowed to assign user passwords to the host and the services. What are network devices for? Actually, okay, okay. Actually, I come to that later if the time permits. Just a few notes on client integration. Clients are deliberately kept dumb. They have just a search base and they have their own credentials and nothing else, no special filters or something like this. Filtering is all done within the Open LDAP server. And regarding the schema, I try to accommodate everything which is legacy out there, especially I have a hybrid group schema which allows to use the same, very same group entry with the member attribute and the member UID attribute. No matter what you configure in your SSSD, for example, it just works. So, and I have support for host maps, you know, and this is what the network device entries are for because network device entries, I come to that later. And what I deliberately do not support is net groups because I find net groups to be really, really bad. I mean, we agreed already on the mailing list about that. So, net groups must die, die, die. So, one application, there was another requirement so that admins do not have direct SSH access to servers anymore. And you can achieve that with running the SSH client with a proxy command establishing a connection to a target system. And this target system, it might have a completely different user management. It might be a weird appliance like hardware security modules or NTP appliances which you cannot directly integrate with LDAP servers. They have strange system accounts, you know, but you don't want everybody to get to this port directly. So, what you basically are doing is in the directory, you add instances for those legacy systems and you pretend that this system is directly integrated with the directory, but it's not. So, you have to, for enforcing this login relationship, which user ID can log into which target, we implemented SSH proxy. In the normal case, that's the usual stuff of doing the SSH login with PAM and SS data and things like that. But only the gateway admins can get really a shell. All others are forced to only start a certain command where they can say, oh, I need a TCP relay to this target. And this proxy command is basically an SSH connection to this gateway. And here you can see this is the user name in the directory. So, this SSH daemon knows this user. And so, this wrapper script asks whether this user is authorized to access this SSH target. So, you have the very same data in your authorization data in your directory, which applies to enforcing the login write for systems which are not even integrated with your directory. Of course, this requires that you restrict SSH access to the gateway. Any questions? How many minutes? So, we're really in a hurry. Two factor authentication is also implemented. It's implemented in such a way that the OTPs, the seeds are really in token entries in the directory. And there's a two level proxy mechanism for validating the typed in user password and the OTP. If somebody is interested, I can demonstrate that later in the coffee corner or something. But the same architecture. And this is a process for enrolling OTP tokens, which is also just implemented in there. You can basically an OTP admin is resetting a token and he gives the user one part of an enrollment password and the other part is sent via email and the user is going to a hardened enrollment client where he types in this enrollment password and plugs in the UBIC key. And then the shared secret is generated here and it's already encrypted with a master secret and written to the token entry. So, and this is a really highly secure process which avoids that on any systems the OTP seed and the user's password are present in clear text. That's what we wanted to achieve by this process. So, time's up. We still have four minutes. Ah, okay. So, we still have four minutes. System manager. This is the future and maybe this is why I typed 2019, I don't know. To come back to your question, a network device entry is mainly a triple with a MAC address, IP addresses, and an FQDN. And you can do a lot of nice things with this if you have this data, if you really maintain a consistent view of this data because you can use it for network access control, the usual stuff, you can use it for OS deployment because, oh, I really hate it. People are setting up OS deployment like, ah, yeah, we have to implement dynamic DNS updates just because they don't have a database where they have the MAC address and the IP address and the FQDN. And if you already have it, you can just use it by adding a very simple DHCP responder just looking in the database. So, very simple. Yeah, and if you have this data, you can just write a wrapper script and you will install the procedure, trapping the data, producing the XML for libvert or something else you might use. And, of course, you can use all this data also for implementing Ansible Dynamic Inventory. That's what I also want to do because this whole system is also set up via Ansible. And I want to issue X509 server certificates in a secure manner because all this relationship between a network device and all the chain going up to a setup admin, I can follow and say, okay, this user account is allowed to request a certificate for a certain hostname. Okay, that's it. Questions? That's the point of the person's pocket. So, what is it? Ah, okay. Yeah. Okay, so this one, I'll repeat the question. What's the person object is for? Mainly, the person object is tied to your HR processes. So, normally you don't maintain person objects manually, so you grab it from the HR department and they are responsible. And each object has metadata with status and lifetime and things like that. So, if this person gets deactivated, all connected user accounts will be immediately deactivated. So that's what it's for. And there are also department object and location object that's on the complete diagram. Okay. Oh, two questions, is that possible? Last question. Last question. So, how is that all implemented underneath? So, you said you have a web UI and is there a product script that's actually doing that? Yeah. Open LDAP, open LDAP server with a configuration, plain open LDAP server, bunch of Python scripts, Python web apps. Okay, thank you.