Kumar,
You are correct. We have our web services in the application-war area of
our enterprise application. So there is the enterprise project, an ejb
project and a war project which comprises the entire application. We have
already tried adding a fourth project just to facilitate a separate web.xml
for our web-service. This works, however, we had expected the GlassFish
server design to accomodate separate security paradigms for web pages and
web services in the same project.
THX
-Michael
On Mon, Dec 1, 2008 at 4:03 AM, V B Kumar Jayanti
<Vbkumar.Jayanti_at_sun.com>wrote:
> Michael Hardy wrote:
>
> 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.
>
> So i guess your web-app and webservice are sharing the same web.xml. But
> since you mention it is an Enterprise App (EAR) can you not create your
> WebService in a separate WAR (with its own web.xml ?) . Sorry if i am not
> seeing your point. Please elaborate.
>
> regards,
> kumar
>
>
> 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
>>>>
>>>>
>>>
>>
>>
>
>