Kumar,
Thank you for the additional information. Below is a snippet from the
security portion of our web.xml.
<auth-constraint>
<role-name>USERS</role-name>
<role-name>ADMIN</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>WebAppRealm</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/LoginError.jsp</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description/>
<role-name>USERS</role-name>
</security-role>
<security-role>
<description/>
<role-name>ADMIN</role-name>
</security-role>
To recap, when <auth-method>FORM</auth-method> is used, form based login
works perfectly, but remote access of web service fails. Switching this xml
element's value to <auth-method>BASIC</auth-method> allows us to use the web
service but the clean customized login form is replaced by the generic
browser-based login. We wish to keep our login form and allow
non-interactive access of our web service.
THX
-Michael
On Thu, Nov 27, 2008 at 4:52 AM, V B Kumar Jayanti
<Vbkumar.Jayanti_at_sun.com>wrote:
> Michael Hardy wrote:
>
>
>
> On Wed, Nov 26, 2008 at 10:25 AM, Michael Hardy <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> 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
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>>
>
>