1 2 3 Previous Next

kalali

75 posts

I have been blogging for the past 4 years in my java.net blog which is now 301 redirected to its new home at kalali.me. In mid 2006 I joined Netcat 50, NetBeans quality asurance team for netbeans 5.0 release, and it was the starting point for me to get involved with Java community in more open way and lead to filing a request to get a weblog at Java.net.The main reason and motive behid starting the blog was sharing my experience about NetBeans platform and java development but in years the blog grown up to a point where I post 6 chapters of my unpublished GlassFish book there and post many other long articles discussing Java EE and other topics including security and software architecture among others.In the past 4 years, I post 74 blog entries and

In this part we will discuss the basic classes that we will work with them to have file system operations like copying a file, dealing with symbolic links, deleting a file, and so on. I will write a separate entry to introduce classes which are new to Java 7 for dealing with streams and file contents, watching service and directory tree walking. If you want to know what are new features in Java SE 7 for dealing with IO take a look at

OpenESB project initiated by Sun Microsystems to develop and deliver a high performance, and feature rich implementation of Java Business Integration (JBI) under an open source friendly license. Basic task of JBI implementations is connecting different type of resources and applications together in a standard and none intrusive way. Basic building blocks of an ESB includes the Bus which is a message driven engine and transition path which deliver the required message to designated binding components. These components are the second main set of artifacts which an ESB has. The main tasks of binding components is receiving the Bus standard format messages and deliver them to other software in a format that the particular software can use. The third set of artifacts is Service engines which can relates the Bus to other types of containers like Java EE containers, transform the messages before they enter the Bus, perform routing related activities over the Bus messages.

The Main concept behind the JBI was around for quite some times but in recent years several factors helped with this concept to further evolve. First the increasing integration problems, second the SOA acceptance level between companies and finally introduction of JSR-208 specification by JCP which provides a common interfacing mechanism for JBI artifacts.

The increasing problem is nothing but the urge for integrating different software which is running in different department of the same enterprise or different partners across enterprises. An ESB implementation can be a non intrusive enabler product for integrating different software running in different department or enterprises without or with very small amount of changes in the software itself.

The concept which helped ESB to become very well known and popular is the Service Oriented Architecture (SOA) in which an ESB can play the enabler role because of its modularity and loose coupling nature.

I will write a series of blog to discuss what are the new features introduced in NIO.2 (JSR 203). The NIO.2 implementation is a part of OpenJDK project and we can alreay use it by downloading a copy of OpenJDK binary.

I decided to write down the answer for some questions which my book's readers email me or ask me via twitter in my weblog so everyone can benefit from the answers. Here is the answer to the first question which involves custom security realms.

GlassFish supports 5 types of security realms out of the box which are sd follow:

 

  1. File Realm: Usefull for development and testing purposes. GlassFish provids a user/ group management interface for this realm. We can add user and groups using the administration console. When using this realm all usernames, passwords and groups are stored in a plain text file.
  2. JDBC Realm: In production environment we store user information including but not limited to username, passwords and groups in an RDBMS and then configure a JDBC realm to authenticate the given credentials againts the information stored in the datase.
  3. LDAP Realm: Sometimes we have all user details stored in an LDAP like Active Directory or Redhat Directory Server, OpenDS or Sun Java System Directory Server Enterprise Edition.
  4. Solaris Realm: This realm is used to authenticate users with a Solaris user directory.
  5. Certificate Realm: The certificate realm allows us to conduct mutual SSL authentication based on the client certificates.


Sometimes our users information is stored in a silo different than all of this mentioned storages and we need to use that source for authentication and access control. For example assume that we have our users information including username, passwords and group membership stored in an Object Database and we need to authenticate our enterprise application's users with that storage. In such times we should either think about having a synchronized RDMBS keeping update user information and use JDBC realm for authentication and authorization or we should develop

Java EE Security refcard is available for download. This refcard covers Java EE 6 security and discuss how each application server supports the specs. The refcard covers authentication, authorization, and transport security in Web Application, EJB application and web services by introducing the concept and the related annotations and deployment descriptors which help us realize the concept.

GlassFish, Geronimo and JBoss are discussed in the refcard to show how we can use the vendor specific deployent descriptors for implementing the security design of our applications.

Following list shows how what are covered in this.

 

  • Security in Java EE applications
  • Authentication an Authorization in Java EE
  • Web Applications Security
  •  

    • Authentication and Authorization in Web Module
    • Enforcing Transport Security
    • Other Security Elements of Web application deployment descriptors
    • Using Annotations to enforce security in Web modules
    • Programmatic Security in Web Module
  • EJB Applications Security
  •  

    • EJB module deployment descriptors
    • Security Annotation of EJB modules in Java EE 6
    • Securing EJB Modules programmatically
  • Application Client Security
  •  

    • Security enforcement in Geronimo ACC
    • Security enforcement in JBoss ACC
  • Defining Security in Enterprise application level
  • Securing Web Services in Java EE

 

  • Web Services Security in Web Modules
  • Web Services Security in EJB Modules
  • Web Services Authentication in GlassFish
  • Web Services Authentication in Geronimo
  • Web Services Authentication in JBoss

The refcard comes with 4 figures showing relation between different element and components in Java EE

Please use the following articles while I am updating this entry

The Book in Details:

Security was, is, and will be one of the most important aspects of Enterprise Applications and one of the most challenging areas for architects, developers, and administrators. It is mandatory for Java EE application developers to secure their enterprise applications using Glassfish security features.

Learn to secure Java EE artifacts (like Servlets and EJB methods), configure and use GlassFish JAAS modules, and establish environment and network security using this practical guide filled with examples. One of the things you will love about this book is that it covers the advantages of protecting application servers and web service providers using OpenSSO.

The book starts by introducing Java EE security in Web, EJB, and Application Client modules. Then it introduces the Security Realms provided in GlassFish, which developers and administrators can use to complete the authentication and authorization setup. In the next step, we develop a completely secure Java EE application with Web, EJB, and Application Client modules.

The next part includes a detailed and practical guide to setting up, configuring, and extending GlassFish security. This part covers everything an administrator needs to know about GlassFish security, starting from installation and operating environment security, listeners and password security, through policy enforcement, to auditing and developing new auditing modules.

Before starting the third major part of the book, we have a chapter on OpenDS discussing how to install, and administrate OpenDS. The chapter covers importing and exporting data, setting up replications, backup and recovery and finally developing LDAP based solutions using OpenDS and Java.

Finally the third part starts by introducing OpenSSO and continues with guiding you through OpenSSO features, installation, configuration and how you can use it to secure Java EE applications in general and web services in particular.

Inspired from real development cases, this practical guide shows you how to secure a GlassFish installation and how to develop applications with secure authentication based on GlassFish, Java EE, and OpenSSO capabilities.


What you will learn from this book :

 

  • Develop secure Java EE applications including Web, EJB, and Application client modules.
  • Reuse the security assets you have by learning GlassFish security realms in great details along with the sample for each realm.
  • Secure GlassFish installation including operating system security and JVM policy configuration.
  • Secure Java EE applications using OpenSSO and set up Single Sign-On (SSO) between multiple applications.
  • Secure web services using Java EE built-in features, OpenSSO and WS-Security.
  • Secure network listeners and passwords using GlassFish provided facilities.
  • Learn using OpenSSO services, SDKs, and agents to secure Java EE enterprise applications including Web Services.
  • Learn using OpenDS both as administrator and as an LDAP solution developer.
  • All command lines and more than 90% of the book content applies for both GlassFish 3.x and 2.x.


Approach

Security is driven by requirement and design and we implement security on the basis of the requirements provided by analysts. In this book, we take a programmatic approach to understand Java EE and GlassFish security.

You will find plenty of code samples in this book. It is easy to secure your application when you have a demonstration of a complete and working application explained in the book, isn't it? Each chapter starts with the importance and relevance of the topic by introducing some Java EE applications requirement, which will encourage you to read it further.


Who this book is written for

This book is for application designers, developers and administrators who work with GlassFish and are keen to understand Java EE and GlassFish security.

To take full advantage of this book, you need to be familiar with Java EE and GlassFish application servers. You will love this book if you are looking for a book that covers Java EE security and using GlassFish features to create secure Java EE applications, or to secure the GlassFish installation and operating environment and using OpenSSO.


Manage, Administrate and Monitor GlassFish v3 using Application Server Management Extensions (AMX) & The Java Management Extensions (JMX)

Management is one of the most crucial parts of an application server set of functionalities. Development of the application which we deploy into the server happens once with minor development iteration during the software lifecycle, but the management is a lifetime task. One of the very powerful features of the GlassFish application server is the powerful administration and management channels that it provides for different level of administrators and developers whom want to extend the application server administration and management interfaces.

GlassFish as an application server capable or serving mission critical and large scale applications benefits from several administration channel including the CLI, web based administration console and finally the possibility to manage the application server by using standard Java management extension or the JMX.

Not only GlassFish fully expose its management functionalities as JMX MBeans but also it provides a very easier way to manage the application server using local objects which proxies JMX MBeans. These local objects are provided as AMX APIs which lift the need for learning JMX by administers and developers whom want to interact with the application server by code.

GlassFish provides very powerful monitoring APIs in term of AMX MBeans which let developers and administrators monitor any aspect of anything inside the application server using Java code without need to understand the JMX APIs or complexity of monitoring factors and statistics gathering. These monitoring APIs allows developers to monitor a bulk of Java EE functionalities together or just monitor or single attribute of a single configuration piece.

GlassFish self management capability is another powerful feature based on the AMX and JMX APIs to let administrators easily automate daily tasks which can consume a handful amount of time without automation. Self management can manage the application server dynamically by monitoring the application server in runtime and changing the application server configuration dynamically based on predefined rules.

1 Java Management eXtension (JMX)

JMX, native to Java platform, introduced to let Java developers have a standard and easy to learn and use way for managing and monitoring their Java applications and Java enabled devices. We as architects, designers and developers of Java applications which can be as small as an in house invoice management or as big as a running stock exchange system need a way to expose management of our developed software to other industry accepted management software and JMX is the answer to these need.

1.1 What is JMX?

JMX is a part of Java Standard edition and was present from early days of Java platform existence and seen many enhancements during Java platform evolution. The JMX related specifications define the architecture, design patterns, APIs, and services in the Java programming language for managing andmonitoring applications and Java enabled devices.

Using the JMX technology, we can develop Java classes which perform the management and monitoring tasks and expose a set of their functionalities or attributes by means of an interface to which later on are exposed to JMX clients through specific JMX services. The objects which we use to perform and expose management functionalities are called Managed Beans or MBeans in brief.

In order for MBeans to be accessible to JMX clients, which will use them to perform management tasks or gathers monitoring data, they need to be registered in a registry which later on let our JMX client application to find and initialize them. This registry is one of the fundamental JMX services and called MBean Server.

Now that we have our MBeans registered with a registry, we should have a way to let clients communicate with the running application which registered the MBeans to execute our MBeans operations, this part of the system is called JMX connectors which let us communicate with the agent from a remote or local management station. The JMX connector and adapter API provides a two way converter which can transparently connect to JMX agent over different protocols and provides a standard way for management software to communicate with the JMX agents regardless of communication protocol.

1.2 JMX architecture

The JMX benefits from a layered architecture heavily based on the interfaces to provide independency between different layers in term of how each layer works and how the data and services are provided for each layer by its previous one.

We can divide the JMX architecture to three layers. Each layer only relay on its direct bottom layer and is not aware of its upper layer functionalities. These layers are: instrumentation, agent, and management layers. Each layer provides some services either for other layers, in-JVM clients or remote clients running in other JVMs. Figure 1 shows different layers of JMX architecture.

http://docs.google.com/File?id=ajhfp4djcnw6_453d85ffcdw_b

Figure 1 JMX layerd architecture and each layer components

Instrumentation layer

This layer contains MBeans and the resources that MBeans are intended to manage. Any resource that has a Java object representative can be instrumented by MBeans. MBeans can change the value of object

Once again the FUD around Solaris and OpenSolaris fate started to spread after Dana Blankenhorn misunderstood the licensing terms and used a eye catching and visitor increasing title, Oracle taking back OpenSolaris, for his blog entry. Well, from this article we can get that even the veteran writers can get things wrong and spread incorrect news :-)

Folks, Solairs is one of the biggest Sun assets that Oracle is now own by taking over Sun . Solaris and OpenSolaris are going to be around in a much better shape than before because Oracle is betting its fight for the market share on this operating system to form a complete stack including storage, hardware, OS, middle-ware, support and so on.

Oracle may change the licensing terms for the Solaris OS, which is the Commercial distribution of OpenSolaris (with some added/ removed components) supported by Sun in old era, but to close the OpenSolaris code-base, no way. Changing the licensing terms can be result of Oracle seeking a higher revenue stream from the product and I bet Oracle will be able to get more out of Solaris than Sun because of its powerful marketing department :-P

Looking at the these FUD from any angel tells you that they are not correct because of at least the following reasons:

 

  • OpenSolaris has a large community around it which Oracle do not like to send away.
  • The Solaris/ OpenSolaris adoption highly increased after Sun pushed the source codes into OpenSolaris project. The whole Solaris on Z architecture, adoption of OpenSolaris increased so adoption of Solaris itself. Long story short, just take a look at http://www.genunix.org/ and http://hub.opensolaris.org/bin/view/Main/downloadsto see how many active distributions are based on OpenSolaris core.
  • Solaris/ OpenSolaris is more important to Oracle to let it fall apart


Extending GlassFish CLI and Administration Console, Developing the sample Modules

Administrators are always looking for a more effective, easier to use, and less time consuming tool to use as the interface sitting between them and what they supposed to administrate and manage. GlassFish provide effective, easy to access and easy to simple to navigate in administration channels which cover all day to day tasks that administrators need to perform. But when it comes to administration, administrators usually write their own shell scripts to automate some tasks; they use CRON or other schedulers to schedule automatic tasks, and so on to achieve their own customized administration flow.

By using GlassFish console, it is simply possible to use shell scripts, or CRON to further extends the administration and facilitate the daily tasks. But sometimes it is far better to have a more sophisticated and mature way to extend and customize the administration interfaces. GlassFish provides all necessary interfaces and required services to allow administrators or developers to develop new modules for GlassFish administration interfaces to add a new feature or enhance already available capabilities.

GlassFish administration channels extendibility is not only for easing the administrator tasks to customize the administration interfaces, but also it is present to let container developers develop administration interfaces for their containers fully integrated with already available interfaces and fully compatible with the present administration console look and feels. Using administration console extendibility developers can develop new administration console commands very easily by utilizing already available services and dependency injection which provide them with all available environmental objects that they need.

This article covers how we can develop new commands for the CLI console and how we can develop new modules to add some new pages and navigation nodes to web administration console.

Spring framework is one of the biggest and the most comprehensive frameworks Java Community can utilize to cover most of the

Modularity is the essential design and implementation consideration which every software architects and designers should have in mind to get an easy to develop, maintain and extend software.

GlassFish is an application server which highly benefits from a modularity system to provide different level of functionalities for different deployment and case studies. GlassFish fully supports Java EE profiles, so it provides a lot of features which suits different case studies and different type of use cases. Every deployment and case study requires a subset of functionalities to be provided, administrated and maintained so, both GlassFish users, application developers, and GlassFish development team can highly benefits from modularity to reduce the overall costs for development, maintenance, administration and management of each deployment type that GlassFish supports.

Looking from functionalities point of view GlassFish provides extension points for further extending: administration console, CLI, containers, and monitoring capabilities of GlassFish application server in a non-intrusive and modular way.

From development point of view, GlassFish uses OSGI for module lifecycle management while it uses HK2 for service layer functionalities like dependency injection, service instances management, service load and unload sequence, and so on.

Looking from integration point GlassFish modular architecture provides many benefits for different level of integration. In bigger picture Glassfish can be deployed into a bigger OSGI container which for example may be running your enterprise application, GlassFish has many advanced subsystem like its monitoring infrastructure

Filter Blog

By date: