Hi Rajeev,
Sreeni passed your msg on to me. I welcome your interest in the jacc and
jsr 196 spis and will help you as best I can.
Glassfish implements the servlet and soap profiles as defined in the jsr
196 (i.e., jaspi) specification. An rmi-iiop profile has not yet been
completed, and as such, Glassfish does not currently support injection,
via the jsr 196 interfaces, of message layer authentication mechanisms
in the iiop ejb invocation path. We expect to define such a profile, and
to implement in Glassfish, but that is a little down the road.
Using the current Glassfish codebase, you can use the jsr 196 interfaces
to inject a message layer authentication subsystem in the
soap/webservices ejb (ore servlet) invocation path. As such you could
use the jsr 196 spi to integrate a new message layer authentication
mechanism on the path to the invocation of an ejb based web service
endpoint.
Alternatively, you might turn your focus to the servlet profile, and
develop a server authentication module (i.e., SAM) for use in processing
servlet layer security constraints. You can see an example of a Servlet
layer SAM at:
http://spnego.dev.java.net. The spnego SAM can be used to
add support for the Http Negotiate extension (i.e. Kerberos
authentication) to the Glassfish servlet container. I am working on a
SAM for openid, and you might choose to develop a sample that describes
how to develop and integrate a SAM that supports an authentication
technology of your choice.
I would suggest that as a potentially interesting first step. You might
begin by creating a SAM that creates authentication sessions that may be
used to interact will any of the applications running on the application
server. In your phase 2, you might revise the functionality of your SAM
such that it acts as an agent to a shared network authentication
service, and such that it produces authentication sessions that provide
cross-system sso functionality. The openid SAM that I am working on is a
example of the latter.
In a third phase, you might create a sample that shows how one replaces
the policy subsystem used by the application container. You might
similarly divide this into 2 phases. In phase 1, you might develop a
simple localized policy provider, and then in phase 2, you might create
an agent to a centrally stored and administered policy provider.
Hope this helps,
Ron
>
> Rejeev Divakaran wrote:
>
>> Hi,
>> This is my first attempt to contribute to glassfish-sample project.
>> I would like develop a sample application demonstrating the usage of
>> JACC and JASPI with glassfish.
>> Phase 1:
>> This will be a simple Stateless session bean (didn't seen the profile
>> for EJB container in the specification; hope it is supported) with
>> Authentication and Authorization modules at server side and Secure
>> request and validate response modules at client side. user in
>> formation shall be persisted in a file.
>> Phase 2:
>> Implementing SSO using JACC and JASPI across multiple application servers
>> LoginModule will do the actual authentication via web service and a
>> token will be returned.
>> The token will be saved at the client side and will be sent with
>> subsequent requests to another application in another application server.
>> As the Authentication module is same it will understand the token and
>> will validate the same with log on web service.
>>
>> I need help in configuring JACC and JASPI provider classes in
>> glassfish server and client side.
>> Please send me any info related to this.
>>
>> Please approve this sample application development.
>>
>> Regards,
>> Rejeev.
>
>