Configure identity and security for a real-world scenario

[radu]

Hi All,

I have an application with an end-user customer frontend and administrator employee frontend. Ideally, I should be able to have multiple war app in the same ear application, each with his own context root and with assigned virtual host. I will have the employee virtual host visible from my LAN, and customer interface assigned to a virtual host with a public name. And start with individual authentication and authorization from here.

The application should have different authentication and authorization logic, different login pages, different error pages.

As not being able to have multiple war’s in the same ear the seam security from pages.xml will force you to have only one login-view-id per application and one identity login method for everybody.

My scenario is not complicated and very usual:

The application will be used by internal employees and by customers (external organization users).
I need one login page for customers, one for employees (I was not able to achieve this with navigation rules and page restrictions).
I need to authenticate customers from one table, and employee from LDAP.

I don’t like the idea that after a customer log’s in on my site only a flag from the Roles table will keep him away from internal sensitive data (invoices, orders, contracts, …).

There is any way to achieve this scenario without having to override all seam Identity classes and methods?

I think seam is all about productivity and fast development time, but I already spent a lot of time with “minor” enterprise requests like this one.

If anybody used seam in enterprise applications, can you please share your experience and architecture ideas?

[swd847]

I have to do something similar. I separated the pages for the external and internal users into separate directories. Then i used a blanket page action to enforce security, so if the current user tried to access a page from the wrong directory a security exception would be thrown.

In terms of separate login pages I would make your login-view-id a 'fake' view, one without a .xhtml file and only a pages.xhtml action that redirects appropriately. By examining the view-id stored in the redirect component you can figure out which pages the user was trying to access and redirect them appropriately.

In terms of the separate authenticators that should not provide any real trouble. Load the user from the database based on username, check if it is an employee or not and then delegate to the appropriate authentication mechanism.

[radu]

Thanks for response, but this is too PHP like to me.

I don't think I need to use a full JEE server and a heavy framework which should provide this OOTB to protect my pages and application with a function call.

This should be in the config files and not hard-coded in a component. What if the business logic will change? I will have to modify my action bean source, re-compile, re-deploy,...

The login-view-id should be present in the <page /> section also if you ask me, will have more flexibility like this.

I need to use the Identity API as the JBoss Portal SSO for SEAM will use also the Identity functions to authenticate users.
I will then need to integrate my application with other solutions and create some portlets which will all share persistence entities.

You should be able to define more jpa-identity-store and ldap-store in components.xml and choose the name of the store you want to use in your function and pages call.

As great as SEAM is for quick development of simple CRUD applications, with missing features like this I don't see how it can be used it in enterprise applications. I feel like I missing the big picture in the very focused examples to demonstrate one feature...

[joblini]

I agree that your scenario of two WAR files is quite typical.  According to these JIRA issues, there is a good deal work to do before this will be supported.
JBSEAM-3119
JBSEAM-2797

I suppose deploying separate EAR files would be a work-around.

It is disappointing to learn that such basic conformance to J2EE has been overlooked.

The Seam literature often boasts of how Seam solves all problems and makes everything easy.  I find this constant sales-pitch grating, distracting, and, at times, infuriating.

Seam is very promising and its developers are certainly very talented and hard working.  I guess that we will have to be patient, after all, the price/quality is hard to beat ;-)

[radu]

Seam is very promising and its developers are certainly very talented and hard working. I guess that we will have to be patient, after all, the price/quality is hard to beat ;-)

I'm totally agree, after all I have choose to use this framework. I'm not trying to criticize the framework or the great work behind, is just that I'm sure that in the years since Seam is out members of this community did use it in big projects with tight requirements.

Will be great to see other developers design decisions made for real projects.