I work for a company with multiple public-facing web sites.
Some of these sites are built using third party products (Moveable Type, myBB, Trac and others). We also have a couple of bespoke sites built on the Microsoft stack.
Currently, we have no unified authentication/authorisation solution; each site implements its own user store.
I'm keen to implement unified user authentication across all sites. I don't expect to achieve single sign-on (it won't be terrible if users are prompted for credentials when switching sites), but I do need each user to have a single username & password.
It seems to me that the most likely solution will be to implement an LDAP server. LDAP is supported by some of the third-party products we use, and I can amend our bespoke sites to use LDAP.
However, I've never used an LDAP store to manage external users (I've always built my own user store).
What are the pros and cons of using LDAP? Have I overlooked other options?
Thanks
Sandy
I don't have experience with OpenLDAP but as pros and cons for the ActiveDirectory-based LDAP:
Pros:
It standardised so quite often there are some binding plug-ins already;
A lot of development frameworks have support for communication with LDAP; (I've done it from PHP some time ago; .NET have a dedicated namespace for that.)
There are all necessary authentication methods and security mechanisms implemented -- passwords are stored securely, authentication with the server can be performed in a secured way if necessary;
Account lockout policy/Password history features can be enabled if needed;
AD have convenient tools for user management, also it can be scripted or accessed via API;
Users can have complex group membership;
Permissions to any object/attribute can be customized;
Directory can be distributed/replicated by adding more domain controllers.
Cons:
Deployment requires some planning;
ActiveDirectory should be regularly back-upped.
If you authenticate against Active-Directory you need a Microsoft licenses.
The license is quite expensive.
LDAP is a great way to store user information in a structured tree. The LDAP protocol also makes it readily available across the web. There are several different LDAP solutions out there but the one you choose will of course be based on your server's operating system. If you have any Microsoft sites your best bet is to go with an Active Directory or ADAM (MS). It is easier to slave a unix machine to an Active Directory than the other way around. If all of your queries will be web-based though and handled through code, then you could use any LDAP source you choose (they're all fairly complicated but with the right tools easy to administer).
LDAP by its nature is lightweight (hence the L) and fast. It's structured for heirarchical access to user information and easy to search based on all of this information. It also has support for an SSL protocol (LDAPS) which I highly recommend.
The cons are the basic heirarchical structure and the differences within the LDAP structures themselves. Active Directory is not a pure LDAP with respect to the RFC but it's close enough that it can be figured out easily.
Related
We have a self-developed proprietary user management and self-developed Single Sign-on. (OpenID Connect wasn't born at that time)
Our authentication server and our thick clients are in a private network, without internet access.
The task is to integrate a third-party thick client - its users should authenticate against our existing authentication server.
The general idea is to use an existing future-oriented framework which offers a standard authentication interface (like Keycloak?) and implement our own OpenID Connect authentication provider (or User storage SPI for keycloack).
Is the way with keycloack and User storage SPI recommendable or are there better approaches?
As you say, this is a good choice for meeting your immediate requirements:
External client uses a modern OpenID Connect flow - eg OIDC for desktop apps
It connects to an Authorization Server with support for standards based endpoints
Authorization Server has extensible support for data sources and can potentially reach out to your existing user data source
As an example, Curity, where I work, supports multiple data sources and there is a free community edition if useful.
Any provider that meets the same requirements would be fine though - and I've heard some good things about Keycloak.
LONGER TERM
It makes sense to then gradually update other apps to use modern OAuth and OIDC behaviour.
At a suitable point it is worth making the Authorization Server the only place from which Personally Identifiable user data is accessed, and moving the storage there. See this data privacy article for some advantages of this.
I can vouch for Keycloak User Storage SPI approach. Recently implemented this for a project and it is working pretty well. For any existing user-database I highly recommend it.
I found some example source on github that you could look at (although needed some modification to run it):
https://github.com/mfandre/KeycloakSPI
I have also written an article summarizing my findings working with Keycloak in case you're interested in other features:
https://dev.to/kayesislam/keycloak-as-oidc-provider-42ip
It's extremely customisable.
I'm aware of various authentication modules for OPAuth, OAuth, LDAP and OpenID for using other systems as login authentication.
My question is which method works to setup authorisation for silverstripe systems from another silverstripe system... so that the users can be solely managed from one installation. All installations are under full control.
I am not talking about subsites... these systems are completely separate - different servers, databases, etc.
Use Case...
AuthSite is the single auth site setup and ClientSiteA and ClientSiteB are both using AuthSite. A User is registered in AuthSite with access to ClientSiteA - this user then can log into ClientSiteA, but not ClientSiteB.
All of the systems you listed will work, however you'll need to code it yourself.
If they're on the same server and you're looking for the quick and dirty solution, I'd probably suggest overriding MemberAuthenticator to use AuthSite's database.
More eloquently, you'd probably want to create some sort of authentication interface on AuthSite which is used by MemberAuthenticatoron ClientSiteA and ClientSiteB. This allows ClientSiteA and ClientSiteB to be hosted elsewhere without having to muck with database settings.
I read some blogs about the LDAP integration in liferay and understood that LDAP is a Lightweight Directory Access Protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
Also it is mainly for user authentication.
Still I am blind in my mind where exactly and in which scenarios do we need to use the LDAP?
Can anyone please explain this in brief with simple real time example.
Liferay as a portal platform also keeps track of user identity. If you have your existing user database already in LDAP (because that's what has been established as a standard) you probably don't want to recreate it in the portal. In fact, many other applications might need this data as well and they all connect to LDAP (again, because that's the standard format).
Thus Liferay allows you to tap into the standard as well.
If you don't have your users in LDAP yet, you might not need to bother. If you start with the user database in Liferay and it grows large, needing to be shared with many other applications, you might want to migrate to LDAP later. And, funny enough, there's also a plugin (EE only) to Liferay that publishes Liferay's user database in the LDAP format. But now we're going quite meta.
I am building a web application with front-end coded in angular. The front-end will access a bunch of web-services coded in Java/Spring. There might be other ways that people may try to access the webservices such as from a desktop tool. Now I need to secure the whole infrastructure.
I need a way to maintain a user repository, i.e. provision users and manage users, roles etc.:
users should be able to register themselves and have their emails verified.
admin should be able to approve users and assign them roles, delete users, update them etc.
I also need single sign on functionality. So once you login through the webfront end, you should be able to access the REST based webservices seamlessly (depending upon the role you have).
I do not need to support millions of users, so something light-weight will be preferable.
I am looking for open-source solution(s) that can:
allow user management (ideally over REST based API and have its own user interfaces as well)
allow single-sign-on functionality for web frontend and webservices, and potentially for desktop apps that may need to be implemented.
I have tried Apache Syncope which seemed promising as it provided REST based APIs. I am thinking of using it with CAS. However, the default UI seemed kludgy and CAS doesn't directly support REST.
I am looking at Shibboleth and OpenIDM as well - but none seems to be meeting my requirement directly.
I'll appreciate any suggestions on what options/stack can I consider for this. Ideally, a single solution or a well integrated solution on Java/Spring stack might work better for me.
you should have a look at https://github.com/openMF/mifosx for Java and Springs RESTFull Web service.
and https://github.com/openMF/community-app for there AngularJS web app.
plus you can also find a live demo link on there repository.
username is mifos and
password is password.
it is ment for microfinance but you can study its architecture implementation and use there core functionalities, it is really amazing.
What is LDAP and why people use LDAP instead of rel. DB?
I've read some about LDAP on Wikipedia, but I'm still confused what is it.
Thank you
As you surely already know, LDAP is a particular sort of database (plus a protocol to access it) for "directory services", oriented towards mostly-read-only, hierachical, distributed scenarios. It's mostly used for authentication, authorization, searching/listing of users with their roles and data (and/or other entities) of some organizations.
LDAP is hated by many developers because of it's very idiosyncratic terminology/idioms, very different from relational databases and SQL. Many had hopes about its slow death, but the fact that Microsoft adopted it for Windows (Active Directory), among other facts, tells it's probably going to be around for some time.
When consider to use it in web applications? Assuming you are not confortable with it, only use if you have to, I'd say. That is, if you need to authenticate/interact with some existing LDAP infrastructure (AD, for example).
LDAP is used to centralize the Authentication and Authorization inside an enterprise network. If a applications has to use the existing infrastructure for Authorization and Authentication then LDAP should be used. By using LDAP you don't have to implement any other authentication logic.
From the Wikipedia LDAP page:
The Lightweight Directory Access Protocol, or LDAP (pronounced /ˈɛl dæp/), is an application protocol for querying and modifying data using directory services running over TCP/IP.
It and similar technologies are most often used in enterprise software to allow centralized management of users and related data. If multiple unrelated applications run in the same environment, using LDAP is a standard way to allow users to use the same credentials and keep system administrators sane.