Security Pattern

[Velmurugan Periasamy]

We're implementing a typical Struts -> Stateless Session Bean Service Layer -> DAO -> Backend application. Why I called it a service layer is becuase there may be other clients than the web app we're building, might interact with the service layer.

I have a basic question on implementing security and want to know how people generally handle it. Basically how do I design the service layer interface without requiring some form of user identification for each method? Or is that the way the service layer supposed to be designed?
Hope I'm making it clear. Basically if we say any method can be called after the authentication is done, this is ok for the web app (since the users cannot do anything until they login), but doesn't this leave a hole?

The other question is regarding implementing the authentication itself.
Let's say we require that each service layer method should pass a security token as well. What's the general strategy for generating a Security Token when the user is authenticated? Where can this token be cached and where do we put the logic of revalidating the security token?

In the past, we've authenticated the users against LDAP or database and stored the login and other authorization information for the user in the HttpSession. This worked because the web app was the only client which was consuming the services. How do I make this generic across the clients?

Thanks.

[Craig Anders]

Hello,

I was attending JavaONE lastweek. I picked up a poster and Book preview chapter illustrates "Security patterns for J2EE applications". It sounded like a patterns effort from Sun microsystems. You may able to find some related information for your problems and particularly contacts from "www.coresecuritypatterns.com".

-C

Originally posted by Velmurugan Periasamy:
We're implementing a typical Struts -> Stateless Session Bean Service Layer -> DAO -> Backend application. Why I called it a service layer is becuase there may be other clients than the web app we're building, might interact with the service layer.

I have a basic question on implementing security and want to know how people generally handle it. Basically how do I design the service layer interface without requiring some form of user identification for each method? Or is that the way the service layer supposed to be designed?
Hope I'm making it clear. Basically if we say any method can be called after the authentication is done, this is ok for the web app (since the users cannot do anything until they login), but doesn't this leave a hole?

The other question is regarding implementing the authentication itself.
Let's say we require that each service layer method should pass a security token as well. What's the general strategy for generating a Security Token when the user is authenticated? Where can this token be cached and where do we put the logic of revalidating the security token?

In the past, we've authenticated the users against LDAP or database and stored the login and other authorization information for the user in the HttpSession. This worked because the web app was the only client which was consuming the services. How do I make this generic across the clients?

Thanks.

[Velmurugan Periasamy]

Thanks for the information.

[Renat Zubairov]

BTW this book is already aviable in Edonkey (P2P) networks.

Originally posted by Craig Anders:
Hello,

I was attending JavaONE lastweek. I picked up a poster and Book preview chapter illustrates "Security patterns for J2EE applications". It sounded like a patterns effort from Sun microsystems. You may able to find some related information for your problems and particularly contacts from "www.coresecuritypatterns.com".

-C