V B Kumar Jayanti wrote:
> 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.
>
You should be able to specify the login-methid used for your ejb web
service by including a login-config element (that specifies FORM as its
auth-method) in the webservice-endpoint elememt corresponding to your
ejb web service (in sun-ejb-jar.xml).
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>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>