Michael Hardy wrote:
> 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
Yes Mike. I am a little concerned that it will be hard to get the
correct content in sun-ejb-jar.xml for the webservice-endpoint.
Ron
>
> On Tue, Dec 2, 2008 at 9:02 AM, Ron Monzillo <Ronald.Monzillo_at_sun.com
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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/>
> <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>
> <mailto: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>
>
> <mailto: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>
>
> <mailto: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
> <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>
>
>