I want to make a web based Java application that reads an LDAP compliant directory and creates a record in a database for each user and group in the directory.
How can i go about it?
I've used the Spring LDAP module to interact with directories. It works very well, same as all Spring code. You would use whatever relational database technology you wish to write to the database. If you're already using Spring, this won't be difficult. In this case you'd create a connection to an LDAP to read the data and another to the database to write it.
But there's a question here that's worth asking: Why do you feel like you need to duplicate the data? The DRY principle would discourage you from doing so. Wouldn't it be better to have all the information in one place or the other?
I don't see how being web-based will affect things, so long as the web server has access to the LDAP directory - you'd use classes under javax.naming.
If you want to access a directory which the browser has access to but not the web server, you'll need to write code to run on the client instead - possible a JNLP application with appropriate access to make network connections.
The general API for talking to directory services (including LDAP) in Java is JNDI (javax.naming).
The official documentation for LDAP is rubbish, but there's a good tutorial on JavaWorld here.
Related
I have 3 different applications
ASP.NET web application
Java Desktop application
Android Studio mobile application
These 3 applications have the same database and and they need to connect from any part of the world with an internet connection. They share almost all the information, so, if you move something in one application it has to update the information in the other 2 applications.
I have the database on a physical server and I want to know how best to make this connection.
I have searched but I couldn't find if I have to connect directly to the server with some SQL Server, using Web Service, or something like that.
I hope someone could help.
Thank you.
I believe the best way is to first create a Web API layer (REST/SOAP) that will be used to perform all the relative operations in the centralized DB. Once that is setup, any of your applications written in any language can use the exposed web API methods to manipulate the data of the same DB.
If you are looking at a global solution - will you have multiple copies of the applications in different parts of the world as well?
In this scenario you should be looking at a cloud-hosted database with some form of geo-replication so that you can keep latency to a minimum.
There are no restrictions on the number of applications that can connect to a specific database - you do not have to create a different database for each and you may be able to reuse Stored Procedures between applications if they perform the same task.
I would however look at the concept of schemas - any database objects that are specific to one app should be separated from other - so put them in a schema for "App1". Shared objects can be in a shared schema.
I have developed a Rest webservice using JERSEY. WIth connects with the oracle database. I have JDBC connection code in my code itself, like the url, IP and username and password. Is is really required to again to configure the database connection on the server? like giving a JNDI name etc. Please help.
Thanks in advance.
Is it really required to again configure
No. It is not required to configure the database on the server, giving it a JNDI name and so forth.
Having said that, JavaEE best practices call for design whereby an application doesn't know the specifics of how to connect to external resources (such as databases). Instead, the application should "look up" that external resource by a logical name, and receives an object through which data can be accessed.
The main benefit in that is that your application code can focus on application functionality, while the application serving environment can take care of low-level aspects such as connection pooling, statement caching and so forth.
The other benefit of following this paradigm is that your application becomes immune to changes in the location of the database: no need to recompile your code, or re-package your application, in order to refer to a different data source. Instead, you could change the data source definition in the application serving environment so it points to a different location, and you're good to go.
I'm currently working on a web application based on Java EE 7, PostgreSQL and the application server GlassFish 4.
I need to implement a form based authentication, and to secure some URL knowing that :
the users and the roles/groups (whatever they are called) are stored in the database.
I wanted my application to be as "standard" as possible (i.e I am currently using JSF and JPA, and no other framework like spring, struts ...)
After some research, I found that Java EE provided a standard authentication mechanism called JASPIC. So, I focused my research on JASPIC and I read multiple Stackoverflow Q/A and those articles written by Arjan Tijms (It's almost impossible to find a Stackoverflow Q/A related to Java EE without one of his answers or comments, thanks to him by the way) :
http://arjan-tijms.blogspot.fr/2012/11/implementing-container-authentication.html
http://arjan-tijms.blogspot.fr/2013/04/whats-new-in-java-ee-7s-authentication.html
http://arjan-tijms.blogspot.fr/2014/03/implementing-container-authorization-in.html
My question is : will JASPIC allow me to do what I need (form authentication + URL restriction with roles) and is it worth the effort to use it ?
What I mean is : it's perhaps safer and easier to use another mechanism.
Arjan Tijms also says that whether or not using JASPIC is "a kind of chicken-and-egg problem" and if JASPIC is safe to use (It doesn't create more problems than it solves), no matter the amount of code I need to write, I really want to be "one of the first chickens".
I'm using JASPIC for my authentication, but JASPIC has one limitation you need to contend with (if you want things standard). You're limited to having no dependencies outside of the Java EE 7 API. This means access to JDBC resources which require a driver is not a capability that is explicitly stated in the standards.
In my OpenID Connect implementation I used Google as my secure store, which also presents me with the Google login form. That is a larger example of using JASPIC though.
For yourself, you can expose an EJB to the global namespace and use InitialContext to get the EJB. There'd be some code duplication in that you have to copy the EJB remote interface code in two places and ensure the serialVersionIDs are the same on both. The EJB can be used to connect to the JPA resources to get your authorization data.
Use EJBs, because the other two options you may think of are REST and SOAP which would be exposing something on your web ports and would require some extra configuration to prevent unauthorized access or require they be placed on a different system.
A simple JASPIC implementation I created in case you want to learn is the HTTP Header JASPIC module which is intended for integration with more complex systems like SiteMinder.
I do no know JASPIC but may I suggest you take a look at the shiro framework
It let's you do pretty much everything you need based on your post with minimal configuration.
For Form based authentication and authorization, you need JAAS. go through follwing url-
linK
I have an Apache Derby database that, until now, has always been locally accessed. It needs to be accessed by multiple computers now, so I feel it ought to have a username/password.
How do I take the existing database and retroactively add a user
How do I provide local/network authentication for that user?
I recall looking through their docs a few years ago, and it seem like there was a lot left to a developer to implement in these cases.
To clarify more, regarding point #1, this page says:
Attention: There is currently no way of changing the database owner once the database is created. This means that if you plan to run with SQL authorization enabled, you should make sure to create the database as the user you want to be the owner.
I think this means that I will probably have to create a new database with a named user, and migrate all date from the original single-user database to the new one. Is this correct? Is there an easier way?
Also regarding question number two, the manual says
Important: Derby's built-in authentication mechanism is suitable only for development and testing purposes. It is strongly recommended that production systems rely on an external directory service such as LDAP or a user-defined class for authentication.
Which, to me, says that the builtin authentication isn't worth using. There's no way we're going to go to an LDAP integration either, so is there something in-between these two that is worth using?
Since you mention you're going from a single-user environment to a multi-user environment, you're probably going to be setting up the Network Server, so you will have two levels of security to consider: database authentication, and network server authentication.
You probably want to start here: http://db.apache.org/derby/docs/10.8/adminguide/cadminapps49914.html
and here:
http://db.apache.org/derby/docs/10.8/devguide/cdevcsecure42374.html
I am designing an enterprise security server for our company - we own many different applications, most written in java and a few written in PHP. I could provide a remote API that would give each application access to the server. I could also create 'agents' that each application could include that would do all the work for them, but allow my server control over their sessions and thus their authentications/authorizations. Issue is I would probably be better to write the agent in java because 80% or more of our apps are in java.
If I wrote the agent in java does anyone know if there was a way this program could access the php session? If not does anyone have a suggestion regarding a better way to go about doing this?
The session data is stored as a (php) serialized array in a temporary folder. The locations for these are set in the php.ini file.
But you can change both the format of the data and the place it is stored (e.g. to a database or shared memory or somewhere else) by writing your own handler.
A quick google suggests that several people have written [de]serializers in Java for PHP data. e.g. http://hurring.com/scott/code/java/serialize/
If you have problems with the built-in PHP serialize function - have a google for WDDX (which IIRC comes as standard) and serializes data into XML.
You might want to think about how you keep the session data appearing to be active to PHP if you want the agent to continue independently of the web session.
C.
You can hook into PHP's session handling using session_set_save_handler() (an example for a simple but complete custom handler is included in the manual). You should be able to synchronize PHP's session management with a central Java server that way.
Your PHP application would receive a session ID through a cookie ($_COOKIE["SESSION_ID"] or whatever).
Your custom session_save_handler would, instead of maintaining a session store of its own, pass that session ID to your central Java-based security server, and get all the session data in return. Writing into a session from PHP would be routed the same way.
You could of course also go the other way, and poll PHP's internal session data from the outside, but wouldn't quite understand what exactly for. If that is the case, can you go into more detail there?