I have a requirement to build build a few REST api that interface with an LDAP V3 compliant server such as open LDAP/ AD. My primary question is if a server is LDAP v3 compliant, does it have its attributes defined per a standard L[as opposed to something like samAccount in AD]? that way it is possible to build a single integration code that integrates with all LDAP V3 severs. so if I have to create/query a user on any LDAP V3 server, I use that same code using standard LDAP attributes and not use vendor specific attributes such as "samaaccount ", or "memberOf". Is this possible at all [just like if I were to write JPA compliant code I could use both hibernate, eclipselink as ORM providers]? or have I misinterpreted LDAP v3 compliance?
LDAPv3 is about capabilities, not about attributes. Depending on which Schemata are used the attributes an LDAP-Server can hold differ. Therefore you can not expect an LDAPv3-compatible server to identify users with a fix attribute-type. You can expect an LDAPv3-compatible server to be capable of understanding SASL, Referrals or Controls. But you will need to make the attributes you need to use configurable depending on the used LDAP-Backend.
The attributes that are used are going to vary from directory to directory and even amongst implementations of the same directory. Every application I've seen that does this properly provides a screen or configuration file for the administrator to map the attributes in the application to the corresponding LDAP directory attributes.
LDAPv3 is a standard protocol, data model and schema that can be extended.
In my opinion, building a service to access an LDAPv3 compliant server must use the protocol and data model, and understand the default/ standard schema, but must be configurable on the attributes, the objectclasses and the directory structure.
Related
I am using Websphere Application Server, that has administrative and application security enabled, which uses LDAP to interface an Active Directory for authentication.
The web application that is deployed to the server is required to be able to retrieve information from this AD, as well as modify information in this AD (such as adding a new user to the AD). I could use JNDI to achieve this, however I need the application to use the settings configured in Websphere to do the connection so that I don't have to maintain multiple sets of LDAP information (one in the application and one in Websphere).
I have searched around but couldn't find anything concrete. The closest I saw was I can configure it as a federated user repository instead of standalone LDAP registry, after which I can retrieve some attribute values, but it does not explain if I am able to modify them.
Any help would be appreciated. Thanks!
If you will use federated repository, then you can use VMM API. It is quite complex comparing to JNDI or ldap related libraries, but should provide you with features you need.
Start by looking at this page - Developing with virtual member manager - and subpages, you will find some code examples there also.
I've created my own JDBC realm (using WildFly 8.2) as described at paragraph 50.3 of the JavaEE 7 tutorial. My understanding is that JDBC realm authentication implies that user credentials are read and checked by the server, the application doesn't even know the coordinates for the auth-reserved DB.
For a "new user sign up", the only thing I can imagine is to implement a classic solution from the inside of my application: accessing auth DB, check if chosen username is already present, insert row in the table... but doesn't this violate the whole paradigm of "container managed authentication", and maybe insert security holes?
Is there some server-implemented mechanism that I ignore?
but doesn't this violates the whole paradigm of "container managed authentication", and maybe insert security holes?
Yes, more or less. The container managed security concept, where the application is totally unaware of the authentication mechanism and the identity store (location where the user data is actually stored) doesn't really take the use case into account where an application has its own user sign up/register functionality.
The idea seems to be more intended for integrating externally obtained applications (e.g. say a Sonar or JIRA instance) into an existing enterprise structure. There the users are created by an admin using a central system like LDAP, or in some situations even an admin UI of the application server.
Unfortunately many of your typical public web applications aren't of this variety. They are standalone apps (don't integrate with existing internal enterprise infrastructure) and they effectively manage their own users.
The classical concept is an ill fit there, and that's why the Java EE Security EG is currently exploring how to best address this.
You basically have three "solutions" in the mean time:
Just define your DB connection details twice, once at the server level, once at the app. It looks like you were indeed already doing this.
Use JASPIC, which is a container provided authentication API which has the option to let the application contain the auth module. It can use the exact same data source and possible JPA entity manager and such that the application is also using.
Do your security using an external security framework, e.g. DeltaSpike Security or Shiro, that's totally implemented in "user space".
From a Java EE perspective, none is really ideal. The first has the duplicate definition and indeed somewhat violates the principle, the second is by itself okay, but JASPIC is a tad low level, and the second is a rich solution but doesn't integrate well with existing Java EE security.
I have an existing JNDI based application where I need to add an RFC4370 Proxied Authorization Control to the LDAP reconnect() method in order to proxy the authorization to the LDAP server (OID 2.16.840.1.113730.3.4.18).
Weirdly, RFC4370 support seems to be missing from the set of controls available in the java.naming.ldap package tree, so it looks like I will need to add an implementation of this control myself.
I am stuck on the generation of the ASN.1 encoding for the control. Looking at the JDK source, the controls are using JDK dependent code to render the ASN.1 (com.sun.jndi.ldap.BerEncoder).
I need to avoid adding large dependencies (but could add an ASN.1 library if it was required), cannot depend on JDK specific internals, and I am not in a position to rewrite this code to use a different LDAP API.
Does anyone have a recommended solution for this?
I have a tomcat server that uses the JNDI Directory Realm to bind to an LDAP server to do authentication and this works fine.
However, I'd like to pull more information from the LDAP server (e.g., name, phone number, email, etc) and wondering what is the best way to do this? So, I see there are two possibilites:
1) Is there a way to piggy-back on this already configured Realm? If so, how?
2) Or do I have to make a separate LDAP connection? If so, can I just the LDAP libraries and routines already in tomcat?
Thanks for the help!
If you need to bind to an LDAP server for retrieving information, go with plain JNDI, it's the standard API for accessing directories and performing CRUD operations over them, it'll just work even outside of Tomcat.
I doubt any container will allow you access to the LDAP connection. There are provisions in some containers to retrieve entries within LDAP itself using LDAP search queries (say to retrieve groups), but containers are usually not designed to share the connection with a developer.
You can use JNDI like Oscar suggests or a host of other APIs. Use a connection yourself since the spec says nothing about sharing connections with you.
JNDI should not be used for new code. JNDI has very little to recommend it:
JNDI has quite a number of software defects
JNDI does not support the full range of the LDAP standards (and makes certain standard LDAP features impossible to use)
the available examples are horrible
it uses a disconnected parameter setting mechanism
and it uses a deprecated configuration.
The UnboundID LDAP SDK supports sensible constructs for connection and LDAP operations.
see also
LDAP: programming practices
LDAP: search
We are currently implementing a portal to our web based services. The portal and services are written with Seam and we are using OpenLDAP to store the security data such as users, groups and permissions. So far we have looked at writing our own code to access LDAP but are there any existing APIs that we could use?
If you're a Spring user, I'd look into the Spring LDAP modules. They're beautifully done; they follow the idiom laid down by their JDBC implementation. Very clean, very nice.
We did this for our web application a while ago and investigated the following:
http://developers.sun.com/sw/docs/examples/appserver/ldap.html
However, we ended up just using the LDAP support built in to Tomcat, since basic authentication was enough for us.
Here is an example on how we set up out authentication in tomcat:
http://blog.mc-thias.org/?c=1&more=1&pb=1&tb=1&title=tomcat_ldap_authentication
JLDAP
The LDAP Class Libraries for Java (JLDAP) allow you to write applications to access, manage, update, and search for information stored in directories accessible using LDAPv3.