Michael Hardy wrote:
> 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.
Yes that is possible as long as you are not sticking to the auth-method
elements which are defined for Web Apps. Specifically if you are
willing to Write a SAM you can do a lot of things (it would mean real
code from your side, though we can help you on that). If you are
willing to use WS-Security for the WebService then again this is
possible, but i realized that your device may not be WS-Security capable.
I will try to get a final word on this after talking to ron.
regards,
kumar
> THX
> -Michael
>
> On Mon, Dec 1, 2008 at 4:03 AM, V B Kumar Jayanti
> <Vbkumar.Jayanti_at_sun.com <mailto: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 <mailto:Vbkumar.Jayanti_at_sun.com>> wrote:
>>
>> 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
>> <http://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>
>>>
>>>
>>>
>>
>>
>
>