Hie Please explain which to use when, OpenDS OpenDJ OpenAM. Thanks.
OpenDJ is an open source project building LDAP and REST base Directory Services. OpenDJ is continuing in open source the development of OpenDS, a project that was started by Sun Microsystems, but abandoned by Oracle.
OpenAM is an open source Authentication, Authorization, Web Single Sign On, Federation solution that is flexible, extensible and highly scalable. For its configuration management, OpenAM embeds OpenDJ. For its user stores, it relies on LDAP directory servers, and is very well integrated with OpenDJ.
[Disclosure: I am product manager at ForgeRock, the company that supports and commercializes OpenDJ and OpenAM]
OpenAM is entirely different from that of OpenDJ or OpenDS. Let me clear all your doubts:
OpenAM is an open source access management and federation server platform, backed by ForgeRock. It was sponsored by ForgeRock until 2016.Now it is supported by Open Identity Platform Community.
What exactly OpenAM is ?
OpenAM provides a service called access management, which manages
access to resources, such as a web page, an application, or web
service, available over the network. Once it is set up, OpenAM
provides an infrastructure for managing users, roles, and access to
resources.
It centralizes access control by handling both authentication
(Confirming the identity) and authorization (Determining whether
to grant access to someone who has authenticated).
When you dive deep inside this beautiful service you will find,You can secure your resources and customize it through Open Access Policy and can implement social authentication, Multi-Factor Authentication ,Account Lockout, Single Sign-On etc. and can define Authorization policies in no time .
Moving on to OpenDJ ..
OpenDJ is a directory server which implements a wide range of
“Lightweight Directory Access Protocol” (LDAP) and also have
support for “Directory Service Markup Language” (DSML). OpenDJ is
written in Java language.
It was an internal project started by Sun Microsystems, which is now maintained by ForgeRock.
Let me help you with those big terms like LDAP and Directory :
Lightweight Directory Access Protocol (also known as LDAP) is an application protocol.
This protocol is used specifically for querying data as well as modifying said data.This is performed by using directory services –that is, a software system that stores, organises, and provides access to the information that is in a directory.
Conclusion:
OpenAM regulates who can access what resource ,when and under what condition while OpenDJ is the high-performance,Highly-available and
secure store for identities managed by the organization.
.
Related
So I want to have single sign in, in all the products using a auth server but that's not only for employees, keycloak should be used to that like auth0?
There are also some advantages to Keycloak:
Keycloak is also available with support if you buy JBoss EAP (see http://www.keycloak.org/support.html). This might be cheaper than the enterprise version of Auth0. If you want to use custom DB, you need enterprise version of Auth0 anyway.
Keycloak has features which are not available in Auth0:
Fine-grained permissions and role-based access control (RBAC) and attribute-based access control (ABAC) configurable via web admin console or custom code or you can write yuour own Java and JavaScript policies. This can be also implemented in Auth0 via user rules (custom JavaScript) or Authorization plugin(no code, less possibilities). In Keycloak you can do more without code (there are more types of security policies available out of the box e.g. based on role, groups, current time, an origin of the request) and there is a good support for custom developed access control modules. Here some more detailed research would be interesting to compare them.
Keycloak also offers a policy enforcer component - which you can connect to from your backend and verify whether the access token is sufficient to access a given resource. It works best with Java Web servers, or you can just deploy an extra Java Server with Keycloak adapter which will work as a gatekeeper and decide which request go through and which are blocked. All this happens based on the rules which you can configure via Keycloak web interface. I am not sure such policy enforcer is included in Auth0. On top of that, Keycloak can tell your client application which permissions you need when you want to access a given resource so you do not need to code this in your client. The workflow can be:
Client application wants to access resource R.
Client application asks Keycloak policy enforcer which permission it needs to access resource R.
Kecloak policy enforcer tells the client application which permission P it needs.
The client application requests an access token with permission P from Keycloak.
The client makes a request to the resource server with the access token containing permission P attached.
Policy enforcer which guards the resource server can ask Keycloak whether permission P is enough to access resource R.
When Keycloak approves, the resource can be accessed.
Thus, more can be centralized and configured in Keycloak. With this workflow, your client and resource server can outsource more security logic and code to Keycloak. In Auth0 you probably need to implement steps 2,3,6 on your own.
Both Auth0 and Keycloak should be able to achieve your goal - assuming you want only social (facebook, google etc), and /or username & password authentication?
Auth0 is the less risky option, keycloak is good for non-commercial & where you can afford production outages without a global 24x7 support team. Here a few other reasons why I'd recommend Auth0 - the documentation is world class, they have quickstart samples so you can get up and running in minutes, and easy access to more advanced options - passwordless, authentication, MFA, anomaly detection, x9's reliability, rate-limiting, an extensive management api, extensions for everything eg exporting logs to log aggregator, and so on. Anyhow, good luck with your project, and obviously what suits best may simply be down to your own project requirements.
Should add, if you are doing mobile, then Auth0 put a lot of effort into adding the necessary specialised security flows to target mobile (native / hybrid) apps. For instance, PKCE usage when using /authorize endpoint. Please bear that in mind, as not certain how keycloak has been implemented to handle this - alot of IDMs still do this incorrectly today.
Problem Statement:
I am trying to build a custom management system which would require authentication and authorization both.
The system needs to have capabilities to manage/create/update/delete users, roles, permissions and groups.
My Design Solution
I am planing to implement this in-house from scratch and would provide authentication and authorization as follows.
Authentication : user would provide their credentials and the system would authenticate if the user is valid or not.
Authorization: once the user is authenticated, based on the user groups and the permissions they could access the requested pages on the site.
Question:
Now, my question is that suppose I have this application built successfully and in future my application requires LDAP (active directory) authentication would it be possible to plug in LDAP related features keeping my existing application intact or I would have to re-write the entire or most application using LDAP API's.
I have had a look at at apache shiro and spring security which
provides LDAP functionality and they also provide capabilities to manage/create/update/delete users.
As of now I have not yet decided if I would go with either of them or write my own.
Would appreciate if I could get a detailed reponse about how to go about things.
Note:
I am a complete newbie to LDAP so please excuse me if I have used some wrong terminology with regards to LDAP.
I would recommend NOT implementing this your self, just integrate with existing API.
Disclosure: I work for Stormpath (which provides exactly this) and on Apache Shiro.
Also, if your application needs to be backed by LDAP, most LDAP setups I've seen only support read operations when integrating with applications, so you may want to chat with your LDAP admin and see if your 'manage' user use case is viable.
Security is a serious domain, with lots and lots of hidden complications. I would definitely recommend against implementing this yourself. Since you mention Spring LDAP, I'm guessing you're in a Spring-based project. The obvious choice in such a setup would be the excellent Spring Security project.
Given there is a requirement from a 3rd party application where LDAP integration is required for authentication, authorization and assignment of users/roles with lookup to directory services or user repository...
When the application environment is Microsoft Server 2012 with WAS to support the application and the server can only access security principals through a web service...
Is there a way to provide LDAP or AD LDS to integrate with the web service or even to sync the local repository with the system of record?
This will probably provide many routes for discussion, but let's assume the application for now can only best subscribe to a LDAP instance for this and AD is not being provided directly to the environment where the application exists AND AD isn't even the system of record - that is exposed from a web service.
This is fundamentally the definition of a meta directory or Virtual directory.
That is, rather than directly contact the directory service for usage, instead there is an abstraction layer, often caching, perhaps uniting data (on the fly per request, or in advance as changes occur).
There are any number of vendors that provide such services in products.
Is there an identity management mechanism available to control/manage user access to a service running on the cloudbees RUN#cloud platform i.e. force log in / sign up etc?
Thanks,
/W
Users you added to your cloudbees domain ("account") can access all services. For a FOSS account, resources are accessible read-only without authentication, but in all other cases login to the platform is required.
Only administrators can subscribe to new services. Jenkins on DEV#Cloud adds RBAC plugin so you can control fine-grain access to jobs and folders.
As far as I know there is no special support from the CloudBees platform for authentication of users of your application: this is just something you would implement in your app using any of numerous available libraries according to language and web framework, using the authentication system of your choice such as OpenID.
In my opinion you should consider Identity access management solutions from TeleSign. You should be able to control user access to services running on Cloudbees Run#cloud platform with ease.
I'm involved in an Java Web Application Migration project to IBM Websphere Portal (IBM WP) Platform.
The actual application in production environment validates manually user credentials (username and password) against a Database Table that stores the data. I understand that the idea behind a Portal application is that the Portal Container handles this Security issues, but I'm not sure how IBM WP can consume the credentials that now are on Database.
There's a brand new Tivoli Directory Server in the Company, and I'm aware that I can't connect IBM WP to this LDAP Server so, do I need to migrate every user in the Database to this LDAP Server, or there's a Way that Tivoli recognize the credentials that are on the database?
Trust Association Interceptor are powerful, but they totally override Websphere Authentication mechanisms, so be sure to write a quite robust one! As Carlos Gavidia suggested, I'd also give a look to Custom User Registry. I'd also suggest to consider Property Extenstion Repository (also know as Lookaside), so you can define your own attributes and read/write them directly from Portal API
http://www-01.ibm.com/support/docview.wss?uid=swg21248674
You can hook in any kind of custom authentication you need using a Trust Association Interceptor. Your custom authenticator would probably work a lot like the authentication code in your existing system. It would display a page prompting the user for their credentials, and then check them against the DB.
I'm not sure how this relates to your Tivoli LDAP, but there seems to be a provided TAI for TAM integration: Tivoli Access Manager Trust Association Interceptor (TAI++)