Jump to content

Centralized Authentication Functionality (LDAP/SSO/HTML Header/RADIUS) [DEVELOPMENT STARTED]


Untoten

Recommended Posts

Well, the query would need to be handwritten by the admin since implementations are too different. So there couldn't be a "selectable group", the group would need to be included in the query.

 

The query would also need a clause with a placeholder for the user name. It would be very inefficient to retrieve all group members just to see if the authenticated user is included (MS AD has a limit of like 1000 results anyway).

So this query - after replacing the user dn - would need to return either 0 or 1 record. This way might appear a bit uncommon at first sight, because naturally you would retrieve the DS object matching the authenticated user and then perform the check. But at this point, when we got the object locally, any check could only be done in code - which wouldn't be user configurable.

 

Authoring LDAP queries can be quite tricky, especially when it's got to include something like checking group membership. For Windows AD, it's not sufficient to query for memberOf, because groups can be nested. Instead you need something special like:

(&(memberOf:1.2.840.113556.1.4.1941:={0})(objectCategory=person)(objectClass=user)(sAMAccountName={1}))

But then, this doesn't return users where the desired group is a user's primary group. For whatever reason...

 

Every other DS implementation has its own specifics and pitfalls, so I'm a bit afraid that this may cause excessive support requests.

 

But let's see what others are saying..

  • Like 1
Link to comment
Share on other sites

1. FreeIPA, which uses 389-DS. Attempting to support individual directory service implementation structures is a very bad idea IMO. Therefore...

2. ...I would prefer custom LDAP queries for users and groups, and custom mappings from LDAP attributes to Emby attributes. Take a look at how Nextcloud does it.

 

E.g.

(emby) -> (ldap)

username -> uid

users -> (memberof=cn=emby,cn=groups,cn=accounts,dc=domain,dc=tld)

Edited by mueslo
  • Like 1
Link to comment
Share on other sites

Attempting to support individual directory service implementation structures is a very bad idea IMO. Therefore...

 

That has never been the plan, it will be a generic implementation! And no doubt that a mapping configuration is required. All of the options I mentioned would imply this.

 

I'm asking about DS implementations once for curiosity, to better understand customer scenarios, but also to choose a few to perform tests against. A generic implementation requires a bit more work than to target just two or three specific ones.Maybe not for coding but for testing and making sure that it's broadly compatible.

 

For the latter, we're counting on you guys to help...

Link to comment
Share on other sites

otispresley

For me, this is:

  1. MS Active Directory
  2. Selectable by group. It is easy enough to create a user group in AD to handle this. The query option can be provided for Advanded usage if the simpler group option is not sufficient.
  • Like 3
Link to comment
Share on other sites

For me, this is:

  • MS Active Directory
  • Selectable by group. It is easy enough to create a user group in AD to handle this. The query option can be provided for Advanded usage if the simpler group option is not sufficient.

This is what I was waiting for years now. If I can integrate Emby with AD for auth it will be awesome!

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

I don't think that AD is widely used here. Cause it's a proprietary Implementation which is overkill and much too expensice for home usage. It's more relevant to companys where they're relatively much forced to use AD cause they need a Windows infrastrukture for their software to work. Altough Emby uses the old .NET framework and not .NET core (which runs natively on linux), it works very well on linux. So there is no reason to provide it on a expensive Windows box. 

 

For me I'm using Apache DS as directory server, but would be also interested in OpenLDAP. Especially OpenLDAP seems some kind of standard in the open source linux environment. Seems like many people use them. 

 

I share the idea to keep a look on Nextcloud. I'm also running Nextcloud on my server and its working very well (all in Docker containers). The idea of approvals or white/blacklist seems not good for me. It's a de facto standard on LDAP to use at least groups for authorisation. Or better provide custom filters, which is the most flexible solution in my oppinion. The idea behind a directory is to keep all those stuff managed in the directory. It's annoying when you have to make changes in every single application after adding a new user to the directory service. The best situation would be: Create a user, add him to a group (like Nextcloud-Users) and he has proper permission. If the user is keept out of the group or got deleted, the app should detect this and denie access. 

 

The biggest issue in my point of view are some tricky differences across directorys. A good example is memberOf. I like the idea behind this, cause it's a waste of ressources to query ALL group for a user. Instead, the user-object should provide information, in which groups he is a member. OpenLDAP support this, but ApacheDS don't. Earlier, I spend some time to make it work there, to benefit from the attribute. It doesn't work as espected. I ended with a custom memberOf field, but maintenanced by me. A acceptable solution for my case, since I only have a few users and new ones are not often generated. 

 

To handle this, you should provide configuration options for all impotant things like attribute mappings. So you can be compatible with as much directory services as possible. As I said, nextcloud is a good example here. Their LDAP config works well with many different directory services. 

 

I'm glad that LDAP is finally on the roadmap :) Emby is the only applicaton where I had to manually create redundant user accounts cause all other apps like Nextcloud are connected and managed using my ApacheDS directory server 

Link to comment
Share on other sites

 Altough Emby uses the old .NET framework and not .NET core (which runs natively on linux),

 

Hi.  We now run almost entirely on .net core.

  • Like 1
Link to comment
Share on other sites

Hi.  We now run almost entirely on .net core.

 

Hi, some time ago I took a look and saw that you're running exe files with mono. But great to here, that you keep up with the time and use .NET Core. Its a great framework I already used for ASP.NET Core applications. Runs stable on linux with a very low footprint, even lower than NodeJS. It's surely the greatest innovation that Microsoft provide here since .NET exist  :)

 

But a big drawback is the lack of LDAP support in .NET Core. Last year I wrote a .NET 1 application which should authenticate against LDAP. The System.DirectoryServices were not ported yet. The only solution I found was https://www.nuget.org/packages/Novell.Directory.Ldap.NETStandard/ which is a port from a very old Novell library. It was orginally written in Java. It wasn't really fun to work with it cause the API wasn't on that level I'm comfortable from the old .NET framework. It also wasn't too stable. On some places we got random expections and need to use dirty hacks like a small Thread.Sleep() to work around them. It would be possible to make them relatively stable by writing a wrapper, but it's some kind of work I don't expect from a library. Not even the naming conventions of this library appls to the C#/.NET Core ones. 

 

Don't know how the situation is nowadays. Are we having a better library now? Does the one from Novell provide better quality now? Seems like they got an update a few months ago. 

Maybe one day Microsoft is doing his homework and port their DirectoryServices to .NET Core. Think this would be the best solution. 

Edited by Th3Dan
Link to comment
Share on other sites

otispresley

I don't think that AD is widely used here. Cause it's a proprietary Implementation which is overkill and much too expensice for home usage. It's more relevant to companys where they're relatively much forced to use AD cause they need a Windows infrastrukture for their software to work. 

 

This is not entirely true. It is possible to Configure Samba as an AD Controller on Linux for free and join both Linux and Windows computers to it.

Edited by otispresley
  • Like 1
Link to comment
Share on other sites

This is not entirely true. It is possible to Configure Samba as an AD Controller on Linux for free and join both Linux and Windows computers to it.

 

Yes you're right, I already heard from the possibility to run some kind of AD on Linux using Samba. Altough I haven't used this. And I also don't think that much users have a AD at home, nor using a Windows Server DC or some third party tools like Samba. This must be installed and configured. Futhermore, you need at least the Pro Edition of Windows on every machine, so that the client is able to do a domain join. What I want to say in my last post is, that there are not much users running a entire AD at home. It may a good idea in a large family with a lot of computers, where features like GPOs make sense.

 

But that's just my feeling. May I'm wrong. Saw a few people here posting that they're using an AD. Would be interesting to hear what stack they're running and for what it's used. I just remembered that e.g. some students got free licences for parts of Microsoft products like Windows Server using academic agreements. So there could be students that don't care about open source running MS AD on Windows Servers. 

Link to comment
Share on other sites

otispresley

But that's just my feeling. May I'm wrong. Saw a few people here posting that they're using an AD. Would be interesting to hear what stack they're running and for what it's used. I just remembered that e.g. some students got free licences for parts of Microsoft products like Windows Server using academic agreements. So there could be students that don't care about open source running MS AD on Windows Servers. 

 

I for one am using Windows Server 2016 Standard on my home network with AD, DNS, NPS, Hyper-V, and Essentials enabled. I have my Windows 10 Pro PC and a Linux VM added to the domain so that I only need one username and password to log into the machines. I am using NPS integrated with AD to log into my router, switches, and AP's. I am running DHCP on my VyOS router VM and having it update DNS in Windows Server. I mainly use Essentials for easier user and share management and for integration for Stablebit Scanner and DrivePool. I also use AD integration for Nextcloud. Emby is really the only thing on my network that I cannot use my AD accounts to log into.

Link to comment
Share on other sites

bman212121

Well, the query would need to be handwritten by the admin since implementations are too different. So there couldn't be a "selectable group", the group would need to be included in the query.

 

The query would also need a clause with a placeholder for the user name. It would be very inefficient to retrieve all group members just to see if the authenticated user is included (MS AD has a limit of like 1000 results anyway).

So this query - after replacing the user dn - would need to return either 0 or 1 record. This way might appear a bit uncommon at first sight, because naturally you would retrieve the DS object matching the authenticated user and then perform the check. But at this point, when we got the object locally, any check could only be done in code - which wouldn't be user configurable.

 

Authoring LDAP queries can be quite tricky, especially when it's got to include something like checking group membership. For Windows AD, it's not sufficient to query for memberOf, because groups can be nested. Instead you need something special like:

(&(memberOf:1.2.840.113556.1.4.1941:={0})(objectCategory=person)(objectClass=user)(sAMAccountName={1}))

But then, this doesn't return users where the desired group is a user's primary group. For whatever reason...

 

Every other DS implementation has its own specifics and pitfalls, so I'm a bit afraid that this may cause excessive support requests.

 

But let's see what others are saying..

 

 

I wouldn't get too bogged down on the details, as long as people are aware of the caveats most people are just going to use group membership to assign rights. IIRC the reason why the primary group doesn't get returned is because of some special sauce Microsoft had to do to handle the "domain users" group. Because this is the primary group of every user by default, there are huge performance issues If say you had 500K users in that group and had to try to do certain things with it. So just a lot of 3rd party software that is doing what you guys are planning won't return primary group, so it's a fairly well known limitation at this point. I don't believe nested groups work either on several different services I've setup, so kind of the same deal. It's trivial to just create a new security group and toss users into it, so it's certainly the preferred method. If I had to guess most people would just use memberOf with a DN, and make sure that group isn't the users primary group. You CAN do other things if you really wanted to (make your life miserable) but I think memberOf is the easiest way most users would go with.

 

The one thing that a lot of implementations don't get right though is you can't import more than one group. I've never cared for services that make you toss any users you want to log in into a security group in Ldap, but then you still need to assign them some type of role in the system. So you essentially have to group the users in a more granular way a second time so the program has the user accounts in it's canned groups. Some are worse still and just let you pick what that ldap group is assigned to, and anyone you import gets those rights. The best implementation is if you allow a user to specify an ldapsearch string for each group in your software. So if there is a canned Admins, and a canned users, you can open up each canned group and put in a query that will return whatever scope of users you wanted it to include. This would allow you flexibility of the built in groups. Then if you need more flexibility, you can just create a new custom group in Emby, and check the permissions you want them to have, then you can add an ldapsearch to pick up those users.

 

So an example is I want 5 groups in Emby, Admins(canned), Users(canned), Viewer only(Custom), Record only(Custom), File management(Custom). The canned ones have pre-checked permissions, and I can customize whatever permissions I want to give in my 3 custom ones. Each one of those groups has a separate ldapsearch query, so in ldap Admins might return a group of users from an ldap group called "Emby Admin", I could also have a group for the users called "Emby Users" in ldap, a group for View only called "Emby view only", etc etc. You can create ldap searches that do other things, but that's most likely how people are going to be using them. The only thing you do have to work out on your end is if a user is a member of multiple groups, how you might handle that user. Generally you'd use additive permssions. So if the user is a member of users and record only, you would combine whatever rights each group gives to come up with a permissions list with the all of the boxes checked that is covered by the combined groups.

Edited by bman212121
  • Like 1
Link to comment
Share on other sites

Thanks for all your feedback!

 

@Th3Dan: let's not talk about what others may need or not - let's focus on YOUR needs ;-)

 

@bman212121: Thanks for sharing your experience and your suggestions. I would follow you to a certain degree but we also need to keep it simple and emby doesn't have a concept of groups, so that  idea about multiple groups mapping with aggregation of permissions is very likely not going to happen. 

Link to comment
Share on other sites

KMBanana

My main reason for wanting this was to be able to avoid exposing any part of Emby to the internet before users authenticated.  

I don't actually have a SSO service setup atm, would implement whatever based on what works with Emby.  

 

What I'd like to be able to do is use my nginx reverse proxy to prompt for a username/password, have that be verified with a SSO service (Probably openLDAP running in a docker container) and if successful use those credentials to login to Emby.  

 

Right now if I try to use nginx basic auth it breaks Emby apps except the browser based one.  

 

Would probably use ngx_http_auth_request_module to accomplish this.  

Link to comment
Share on other sites

Untoten

Guys, I am out of the country for work but I'll reply soon. Luke has a rough workflow I described to him a while back.

 

As for user sync workflows, the software our teams have made is sync on task, sync individual user on login, or both. I personally think syncing one user, once they login, with an update per subsequent login is best.

 

Again, I'll reply soon with more detail, but data is expensive here.

Link to comment
Share on other sites

My main reason for wanting this was to be able to avoid exposing any part of Emby to the internet before users authenticated.  

I don't actually have a SSO service setup atm, would implement whatever based on what works with Emby.  

 

What I'd like to be able to do is use my nginx reverse proxy to prompt for a username/password, have that be verified with a SSO service (Probably openLDAP running in a docker container) and if successful use those credentials to login to Emby.  

 

I'm afraid, at the moment we are not planning to implement SSO.

 

It would only be an authentication against a common ldap user database, where users would have to sign-in to emby separately but with the same credentials they are using elsewhere.

 

For actual SSO there's a wide range of standards, e.g. SASL extensions for ldap with a large number of different methods, or also web based implementations like oAuth or SAML.

Whatever method we chose, it would be wrong for many more people than it would be right for.

 

And finally - the web access portal is just one of many different ways for accessing Emby. For most apps, eiher SSO would require specific implementation (different for each SSO variant), or wouldn't be possible at all (whether technically or by policy of the SSO provider).

 

But it's not a 'never' - it's just a 'not now' ;-)

Link to comment
Share on other sites

nstephenh

Hello everyone,

 

I just wanted to say what my intended use case is. Previously I've had usernames/passwords in 3 different locations: a haproxy config of plaintext passwords, emby accounts (with and without passwords, as it was all behind http_auth from haproxy anyway) and then nextcloud's internal authentication. I'm currently switching from haproxy to nginx in an effort to switch to LDAP, using a freeIPA server. My end goal is for all my users to be able to sign in to emby, some sort of webportal for the services that don't have good authentication, and nextcloud with the same usernames and passwords all in one place.

 

That's my use case. If anyone has questions let me know. I'm just learning how to use LDAP, so at this point I'm not 100% sure what I'm doing but I'm learning as I go.

  • Like 1
Link to comment
Share on other sites

Radeon24

Hello,

 

I looked a this post since a long time, and I'm happy to see that the goal is close to us. So, to answer the questions :

1. I use the authentification of my Synology (Directory Server), wich is an implementation of OpenLDAP

2. I think the white list method will be good for many users, or add a filter with a group (generic or customizable).

 

Thanks to the entire team for the work you've done and will do !

  • Like 1
Link to comment
Share on other sites

I'd like to add a few comments to how I think this would make more sense overall.  This would also add additional power to the whole system regardless of if you are using external LDAP/RADIUS/ETC or not.

 

First at present we only have the concept of users in Emby.  What we really need is the concept of Groups and users.  So each user could belong to one or more groups.  Even the most basic home user could make use of this.  Setup a "home group" and set all libraries, plugins, DVR/TV settings this group has access to then create a user and assign them to the home group.  Everyone has the same privs.  Need to remove or add a library just add it to the group(s) and not worry about every user.  I create libraries specific for holidays and seasons such as Christmas, New Years, Valantines Day, ect with movies specific to them.  It would be so much easier to just add this library to a group vs all users.

 

Hopefully the above makes sense and everyone is thinking how they could use this functionality to make their life easier.  This of course would be useful to EVERYONE.

 

Next with the LDAP type approach you verify the username/password and pull back any groups (attributes) the user has that would be associated with Emby.  As long as the admin has setup groups with the same name in both Emby and their AD it becomes very easy to adjust privs, do provisioning etc.  The request to LDAP is essentially very simple since you only care about group attributes that match groups already setup in Emby.

 

In this fashion you could have Emby only accounts or LDAP only accounts or combinations where Emby is checked first then LDAP is checked.  But in all cases the built in GROUPS in Emby would be used for provisioning.

 

Doing this method allows the LDAP code to remain rather minor while the actual Emby code gets most of the updates.  But with or without LDAP you have much more functionality that all Emby Admins could use to make life easier (because of the groups).

 

This way ALL EMBY ADMINS gain from the investment in development time put into this regardless of LDAP/AD use.

 

Thoughts?

Carlo

Edited by cayars
  • Like 3
Link to comment
Share on other sites

Yep, just saying LDAP password checking in and of itself isn't very useful without the ability to auto provision. Using groups ties the whole thing together.  The actual LDAP integration code itself should be rather trivial.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...