Here's a scenario:
I have a java front end (RCP/SWT) app which currently has no authentication support.
I have to however, add security to this application so that it gets deployed in different enterprise envinronments. I have a few approaches which I thought I would share with you all here and take your inputs. Please note that there are no strict requirements yet, so.. I would like you to consider typical and non-typical enterprise network security models.
Approach 1
Create a 'Security' webservice that
the thick client would invoke, on startup.
The client queries the security for the current authentication mode and receives the implementation class of the authentication as a soap attachment. The class received, will not have the logic for authencation, rather it would just describe the UI and the events on the UI. (The client could make use of a GUI toolkit such as Thinlet?)
Once the class is loaded, a UI relating to the currently set authentication method is displayed to the end user.
Advantages:
This approach lets me handle different authentication schemes. For instance, if the app has to authenticate against user names and passwords stored in a database, a screen with UserName and password fields would suffice. However, say the user were to do a network logon that would involved typing in the network name, the UI would contain three fields. If the security model at the client network dictates ntlm/SSO based authentications, the user won't see a UI. This will also leave scope for future authentication methods - for instance, supporting a captcha specific logon screen/ biometric stuff / whatever.
Approach 2
KISS (Keepin in yea.., Simple)
User name and password are usually the only two credentials required by all of the known authenticating mechanisms?
Have the thick client query the webservice and let the webservice handle the entire authentication process.
I am not sure how realistic/feasible/commonly used the above mentioned approaches are. Appreciate your help.
I'd certainly not recommend transmitting class definitions as SOAP attachments. A network classloader would make more sense, but is still not needed in your situation.
Put in the client what belongs there - the UI. Have the multiple screen types ready (i.e. defined as classes) on the client and activate each of them depending on a single value passed by the server. For example if AuthenticationType.CREDENTIALS is passed, go for username/password. If Authentication.SMART_CARD is - go for smart card.
If you want to distribute the application and later implement different auth screens, then use Java Web Start. Thus all clients will be guaranteed to be running the latest version.
After knowing that your requirements impose some limitations, take a look at this network classloaders article.
Related
I'm working on a project which involves writing web services on mainframe enviroment.We are going to be provided a test enviroment on which we can do development and see the inital results. That process is taking a lot of time and I wanted to see if I can simulate some of the parts that I've to do.
Finally I've to get web services talking with mainframes which would have webservice talking with DB2 and IMS segments. I've never worked with mainframes before and I wanted to know how can I create mocks for IMS segment which then my webservice can read and update to. I would appreciate any insights into this
I've done the mainframe side of POX and SOAP web services in CICS. (CICS can access both DB2 and IMS) The thing that seems to surprise the distributed folks is the tag names. They tend to be generated from language structures, so they look like (in our case) COBOL variable names.
Other than that, the SOAP looks like what the WSDL says it should, the POX looks like POX.
If you've got a schema, work from that. Don't worry about the fact that it's a mainframe or that the data is stored in IMS or DB2, write to the specification.
You might want to ask about authentication mechanisms, as this is another stumbling block regardless of platform. Generally people are nervous about unauthenticated access to their business systems, even if that access is coming from another part of the same organization. No one wants to have created an exploitable hole in their security.
In our case, using CICS, we required a logon ID and password for each transaction - http basic authentication as per RFC 2617. Depending on your policies and procedures, that password may be required to expire on a regular basis. Some organizations allow non-expiring IDs, some don't.
An option we looked at but did not implement was SSL certificates. CICS allows one to send a certificate along with a request and then CICS matches the certificate to a logon ID under whose auspices the rest of the transaction runs. The ID is authenticated by virtue of the certificate. This is done in the TCPIPSERVICE definition in CICS.
I realize I'm going on about CICS and you didn't even mention it in your question, but I have to believe you're going to run into similar concepts/issues. IMS also does web services, and I seem to remember there being a mechanism to expose a DB2 stored procedure as a web service. IMS, DB2, and CICS all use the same external security manager behind the scenes.
I have made a Java EE 6 application where a user can browse a set of questions, add new questions and so on. The user can optionally log in so that he/she gets "credit" for adding the question or reporting it as bad.
Now I want to make a iPhone application where the user can do pretty much the same. So the answer is web service I assume. I have not worked with web service before but I see there are at least to alternatives: SOAP and REST.
Which one should I choose? I want the user to be able to log in from the application as well a as browse the questions in the database...pretty much many of the actions you can do on the web site.
I don't know much about the security and overhead they introduce.
Also I want the user to be able to retrieve the list of questions thorugh the web server and have the option to save it, so he/she won't need to have internet unless he/she wants to update it. Can I achieve this with both web services?
REST has less overhead than SOAP (WSDL contract, XML messages, supporting frameworks) so when the client is a mobile device REST seems more suitable. You could use JAX-RS (Jersey) to easily create REST services on the server side. The client request consists of the url structure and/or parameters like http://yourserver/questions/view/342 (to view question 342) or http://yourserver/questions/search?q=REST+vs+SOAP (to search for questions about REST vs SOAP). The response can be anything you want, but XML or JSON is pretty common.
Choosing REST means you will be leaning heavily on the HTTP protocol. For security a common approach is to use HTTP Basic authentication in combination with https. Basic authentication means you add an 'Authentication:' header to your HTTP request containing a Base64 encoded username:password pair. Note that Base64 does not encrypt anything, it just obfuscates. To avoid eavesdropping you need to use at least https meaning requests are encrypted using the server's public key. These requests can only be decrypted with the server's private key. To use https you need to set up the server with a certificate. If you want to avoid warnings about the certificate being 'untrusted' it needs to be issued by a recognized SSL certificate provider. For testing you can just generate it yourself.
Finally you asked about saving a list of questions for offline usage. This is a concern of the app, not of the service. To do this you need to store the retrieved data on the device and access that data if the device goes offline. I am not an iPhone developer, but I can imagine you could use a flat file or some lightweight database to store the data. When the device is offline, the app component that retrieves data should switch from network access to local storage access. Also some app functionalities like adding a question might need to be disabled. If you don't disable these, you would need to temporarily store any data entered by the user and send it to the server when the device comes online again. This could be a bit tricky to get right so my advice would be to leave this for later.
You can take a look at this previous SO post for some guidance. I would recommend using REST, it seems to be less messy than SOAP and Java has support available for it as shown here.
Through the use of annotations, you can simply created a facade to which users will connect. In turn, this facade will call the relevant logic which I am presuming you already have.
Well on a simple search REST vs SOAP, you will eventually get to this
There are plenty of other articles and even in-depth research papers, so it's only a matter of - do you really want to get serious with your research VS not really
Good luck!
Short answer: Yes, you can achieve that with web services.
Web services are only a facade to your system - they can expose (or not) any behavior you want to. If you have security concerns, you'll have to approach them anyway in both methods.
Personally, I'd use a RESTful approach as its usually simpler to implement and use. From Wikipedia:
A RESTful web service (also called a RESTful web API) is a simple web
service implemented using HTTP and the principles of REST. It is a
collection of resources, with four defined aspects:
the base URI for the web service, such as http://example.com/resources/
the Internet media type of the data supported by the web service. This is often JSON, >XML or YAML but can be any other valid Internet media type.
the set of operations supported by the web service using HTTP methods (e.g., GET, >PUT, POST, or DELETE).
The API must be hypertext driven.[11]
So you'd have a URL, say http://mywebsite.com/users and perform HTTP actions (GET, PUT, etc) on them. A GET request on /users/17 could return user 17, for instance, while a POST request on it would update said user.
As for login, when your users "log in" you would call a GET method that sends username:password (probably encrypted) and returns a login token. Every time the user executes an action, you would send said token with the request as an additional parameter.
I want to make my web application able to work offline and as soon as it becomes online or gets connected again, then it should be able to transfer the modifications made by user in offline mode.
I have seen Google Gears as an ideal solution for my problem, which is not recommended to be used as it is now deprecated.
What is a good way to make my application work offline, both in terms of technology to use and application design?
Gears is deprecated because the HTML5 standard allows for equivalent features to be present in compliant browsers.
With respect to your current problem at hand of handling offline web application access, you can look into the support offered by HTML5 for offline web applications via support for client-side SQL database access, and the client-side application HTTP cache.
The features will have to be used in conjunction, as the client-side database access will allow for storage of data (generated when the application is offline) in a structured format, while the offline application cache will allow for caching of HTTP responses from the server; you should not be caching responses that are dynamic in nature which depend on any user-provided inputs.
The details of the proposed APIs can be found in the W3C HTML5 specification, which is in draft at the moment, although it appears that certain user-agents have already implemented this feature.
Firstly, you will need some form of offline storage. HTML5's capabilities are the successor to Google Gears, as stated on the google gears developer blog; essentially, the purpose of Google Gears was just to push the development & subsequent adoption of HTML 5 features.
Specifically you should be looking at the HTML5 offline (here's a tutorial) APIs, and the Storage APIs may also come in handy (relevant tutorial).
With regards to design, you will essentially need to maintain your complete web application state client side, and then send over the differences (i.e. update the server-side state) as soon as the connection to the server is available again.
Off the top of my head, there's 2 simple ways to design this:
Explicitly maintain separate application states for the client and server. Essentially, when the user takes an action, it's applied to the client application state first, and then at specified intervals (and/or triggers, e.g. the user clicks the save button), the client sends over the differences between the last known state of the server and the current state of the client. This is probably best suited to highly interactive web applications, and I suspect Google Docs works on this kind of design. Depending on your application (if "conflicting changes" can occur), you'll need to also account for merging application state: do you override with the last received client state, or do you intelligently try to merge? (you'll have to decide which makes more sense for your particular application.)
Record user actions while offline, and replay them once the connection becomes available again. You essentially implement the Command design pattern, and have both your client-side code and server-side code able to handle each command. The client-side code always handles each command, and while the connection to the server is available, your client side code also sends off the commands to the server. You'll probably want to implement some batching, to avoid continual requests to the server, and also some roll-back functionality when requests to the server fail (e.g. conflicting changes). This ends up looking more or less like GMail's main email managment user interface, where you can undo operations.
This has not much to do with J2EE, but rather how you code your web-client. One possible solution would be to use a javascript client that does save the data in the local storage introduced with html5 (see http://diveintohtml5.ep.io/storage.html ). That is also basically the reason why google gears was stopped ...
I've bean studying JMX for a while, but I'm stuck.
I have an application that exposes some functionality to remote clients via JMX, although existing security features may be sufficiant for most cases my application uses Apache Shiro framework as the security backend.
My problem is that i don't how to gather client data serverside. Shiro needs a way to identify a client (subject), normally executing thread is associated with a subject but online JMX documentation does not give much clue about thread model of remote JMX.
How can i associate a client with a thread or is there a way to retrieve client data inside the interacted MBeans?
After researching and trying different techniques; there are two winners:
1- New feature called ClientContext that will be a part of Java 7: Java 7 is not yet complete, and ClientContext will break backwards compatibility.
2- Attaching Shiro subject to AccessControlContext: This is the solution I choose, Shiro's default subject retrieval mechanism does not consider Java's access control context. I ran a test a long ago to test this but it didn't work. Now I know why: by default SecurityUtils.getSubject() call attaches the retrieved Subject to the currently calling thread, but this approach is useless since threads can be shared between clients. But AccessControlContext is much more powerful, and it looks like JMX plays nicely with it; your access control context (which is authenticated during login at JMXAuthenticator) can be accessed from a MBeanServerForwarder or even inside your MBean. I tested this with a multiple clients retrieving their principal, it simply works.
Edit: How i attach Shiro subject to the current AccessControlContext?
1- Create an unattached Shiro subject using the builder class Subject.Builder.
2- Authenticate the user (using Shiro subject's login method, etc.)
3- Create a mutable JAAS subject with a singleton set containing the Shiro subject as the private credentials.
4- Provide the JAAS subject to the underlying Java security System (for example, Return the subject inside a JMXAuthenticator's authentication method)
A helper class can be created to simplify this approach. When you need an action to be performed on behalf of the Shiro subject (for authorization, etc.), get it from AccessControlContext and use one of the Subject.execute... methods. This can be performed inside a proxy or a forwarder (like MBeanServerForwarder).
I am developing a Data Modeling Software that is implemented in Java. This application converts the textual data (stored in a database) to graphical form so that users can interpret the data in a more efficient form. Now, this application will be accessed by 3 kinds of persons:
1. Managers (who can fill the database with data and they can also view the visual form of the data after entering the data into the database)
2. Viewers (who can only view the visual form of data that has been filled by managers)
3. Administrators (who can create and manage other administrators, managers and viewers)
Now, how to implement 3 diff. views of the same application.
Note: Managers, Viewers and Administrators can be located in any part of the world and should access the application through internet.
One idea that came in my mind is as follows:
Step1: Code all the business logic in EJBs so that it can be used in distributed environment (means which can be accessed by several users through internet)
Step2: Code 3 Swing GUI Clients: One for administrators, one for managers and one for viewers. These 3 GUI clients can access business logic written in EJBs.
Step3: Distribute the clients corresponding to their users. For instance, manager client to managers.
=================================QUESTIONS=======================================
Q1. Is the above approach is correct?
Q2. This is very common functionality that various softwares have. So, Do they implement this kind of functionality through this way or any other way?
Q3. If any other approach would be more better, then what is that approach?
no
no
yes
Making different clients for different security roles is a :
security hole - what if a viewer obtains the administrator version?
hard to maintain
The way to do this is:
make the data transferred to the client dependent on a security check
also make various parts of the UI visible/enabled depending on that security check
the security check is made on the server
the security check depends on the currently logged user
the user logs in on startup, using his credentials (username/password or digital certificate)
the security roles (administrator, moderator, viewer) are stored on the server side.
Then, if needed, you can extend the security model by adding:
differentiation between per-user and per-role rights
rights on specific resources
transitive rights
permissions for specific actions
But such a complex user rights and security model is perhaps not needed in your application.
I agree with #Bozho except for the following:
make various parts of the UI visible/enabled depending on a security check
You actually need to make sure that unwanted access to the data, etc is blocked on the server side, irrespective of whether the client-side UI is visible / enabled. The reason for this is that any client-side UI disabling code can be subverted. Indeed, a bad guy could even entirely bypass your UIs and reverse engineer the application-specific protocols between your client and server code.
This is not to say that you shouldn't also disable / hide parts of the UI that the user is not allowed to use. It is just not a good basis for decent security / access control.
(UPDATE : #Bozho has ammended his answer now to add server-side blocking to his list. So I now agree with it entirely. )
I agree with Bozho. Another points with the three client approach is: what if the user somehow figures out how to send the operations which isn't available in his client? What if the same user has two roles (hence is required to have two clients). And of course you will have plenty to do maintaining one client...