Michael Hardy wrote:
>
>
> On Wed, Nov 26, 2008 at 10:25 AM, Michael Hardy <hardymf_at_gmail.com
> <mailto:hardymf_at_gmail.com>> wrote:
>
> Kumar,
> Thank you for your kind attention to this issue. Both of the
> links below relate to secuity for messaging. Since we do not as
> yet have a Messaging Bean (MB) and do not currently utilize JMS in
> our application, this is not related to the issue.
>
The links that i sent are not related to JMS. They show how a JSR 196
Auth Module can be configured for a WebApplication at the HTTP Layer and
a WebService at the SOAP layer. The Server Auth Module would then allow
you to perform your own custom authentication on the incoming request
before returning the Authentication Status to the Container.
Specifically, the entry :
http://blogs.sun.com/enterprisetechtips/entry/adding_authentication_mechanisms_to_the
shows how you can handle Basic Authentication on your own, by
evaluating the www-authorize header and to issue the www-authenticate
challenge.
> To describe what the needs are further, we have an Enterprise
> Application with CRUD and an Oracle DB backend. We deploy to
> GlassFish with a single ear file and have form-based
> authentication at the front end with users, roles etc. maintained
> in the DB. Using JAAS required that we create a realm and the
> concommitant dependency upon a connection pool and a datasource.
> The application functions as expected and we can allow\disallow
> funtionality presented to the client based upon the users role.
> We have implemented a portion of our functionality as a web
> service. This service, when deployed to the GlassFish container
> is available to local services seamlessly. When needed by a
> remote service, the forms-based authentication is problematic as
> the client application does not have the capability to respond to
> a login prompt presented by the form. When we modify the web.xml
> and switch from FORM to BASIC auth-method, the remote access by a
> client application to the web service works, but our web site
> loses the login form at the front end and now presents the
> standard browser-based login dialog. We hope to maintain our
> current form-based login and utilize either BASIC or, better yet,
> CLIENT-CERT authentication\authorization of a web service in a
> single deployment of an Enterprise Application.
>
Can i see your web.xml.
Does the device have any primitive WS-Security capabilities ( i guess
not) ?. Because with WS-Security you could then use a simple
username/password authentication for the webservice.
Just thinking aloud, You can probably try enabling client-cert
authentication at the http-listener (this would require all apps bound
to the listener to do client auth) without disturbing the FORM login in
your web.xml. I am assuming the device is SSL capable.
<http-listener acceptor-threads="1" address="0.0.0.0"
blocking-enabled="false" default-virtual-server="server" enabled="true"
family="inet" id="http-listener-2" port="8181" security-enabled="true"
server-name="" xpowered-by="true">
<ssl cert-nickname="s1as" client-auth-enabled="true"
ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true"
tls-rollback-enabled="true"/>
</http-listener>
see client-auth-enabled="true" above.
regards,
kumar
> Thank You,
> -Michael
>
> On Wed, Nov 26, 2008 at 12:34 AM, V B Kumar Jayanti
> <Vbkumar.Jayanti_at_sun.com <mailto:Vbkumar.Jayanti_at_sun.com>> wrote:
>
> Hi,
>
>
> Michael Hardy wrote:
>
> Greetings,
> We currently use JAAS and db stored groups and users to
> manage a form-based login. We would also like to have the
> same level of authentication\authorization security on a
> web service we have created. Since the consumer of the
> web service is a client device, we do not wish to use the
> form authorization\authentication method. We have
> verified that using BASIC authentication the conversation
> between device and web service functions perfectly.
> However, this of course precludes our form-based login
> for the web site in our enterprise application. Is there
> a strategy for mixed BASIC and FORM authentication? Even
> better might be a mixed FORM (web site login
> authentication and authorization) and CLIENT-CERT model.
>
>
> Not sure if we understood the requirement very well, but if
> you have a Web App with Form Login and another WebService,
> can they not be two separate deployable modules ?.
> Based on what we understood so far, One thing that you can
> explore is the possibility of using a Server Auth Module (SAM) .
> http://blogs.sun.com/enterprisetechtips/entry/adding_authentication_mechanisms_to_the
> http://blogs.sun.com/monzillo/entry/pluggable_authentication_in_the_glassfish.
>
>
> We were wondering how you would disthinguish between when to
> use FORM and when to use BASIC auth in your current design.
> May be i should wait for some clarification from your side,
> before suggesting anything more.
>
> regards,
> kumar
>
> Thank You,
> -Michael
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
> For additional commands, e-mail:
> dev-help_at_glassfish.dev.java.net
> <mailto:dev-help_at_glassfish.dev.java.net>
>
>
>