Ron,
To recap, you are suggesting that I:
1) create the web service in the application-ejb project instead of the
application-war project
2) create a sun-ejb-jar.xml (rt. click application-ejb project and choose
New | Other | GlassFish | GlassFish Deployment Descriptor
3) edit sun-ejb-jar.xml for type of security desired for web-service (e.g.
BASIC)
4) assumes exisiting security with FORM authentication listed in web.xml
Is this an accurate depiction of what you understand will allow both FORM
and BASIC authentication in a single Enterprise Application?
THX
-Mike
On Tue, Dec 2, 2008 at 9:02 AM, Ron Monzillo <Ronald.Monzillo_at_sun.com>wrote:
> 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>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>