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>
>>
>>
>>
>
>