Re: [S2] Struts with Web Services
We've had great success with CAS. Its pretty trivial to 'cas-ify' a web application and as wes mentioned it is very nice for a single sign on solution. They also have a very active mailing list. On Fri, Apr 4, 2008 at 3:59 PM, Wes Wannemacher [EMAIL PROTECTED] wrote: Production integration experience? No... I evaluated it and did a quick proof-of-concept on a project once. We ended up sticking with the in-house option, which wasn't bad, but it was an apache mod, so we periodically looked for alternatives because we were always tied to mod_jk or mod_proxy because the authentication/authorization service was tied to httpd. The nice thing about CAS was that it can be integrated in more than just Java web-apps. You can also integrate with acegi rather easily. It's worth checking out if you have a suite of web-apps that you would like to create a single-sign-on that is somewhat reusable. -Wes On Fri, 2008-04-04 at 08:56 +0200, Lukasz Lenart wrote: http://www.ja-sig.org/products/cas/ -Wes Do you have some experience with that? It looks quite interesting ;-) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts with Web Services
http://www.ja-sig.org/products/cas/ -Wes Do you have some experience with that? It looks quite interesting ;-) Regards -- Lukasz http://www.linkedin.com/in/lukaszlenart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts with Web Services
Production integration experience? No... I evaluated it and did a quick proof-of-concept on a project once. We ended up sticking with the in-house option, which wasn't bad, but it was an apache mod, so we periodically looked for alternatives because we were always tied to mod_jk or mod_proxy because the authentication/authorization service was tied to httpd. The nice thing about CAS was that it can be integrated in more than just Java web-apps. You can also integrate with acegi rather easily. It's worth checking out if you have a suite of web-apps that you would like to create a single-sign-on that is somewhat reusable. -Wes On Fri, 2008-04-04 at 08:56 +0200, Lukasz Lenart wrote: http://www.ja-sig.org/products/cas/ -Wes Do you have some experience with that? It looks quite interesting ;-) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[S2] Struts with Web Services
Hello, I've been spending the last couple months familiarizing myself with a few java based web technologies, mainly Struts 2, Spring, and Hibernate. I have a decent understanding of Struts, enough to make a few simple example webapps that have helped me learn the concepts (along with a lot of help from this message board!). I'm now trying to design a real webapp that does more than one simple task. The basic idea is that I want a single User database that contains login and registration information (user name, password, name, address, etc). When a user logs in, they are presented with a home page that shows them all of the resources they are able to access (things like product updates, product information, trial keys, etc). Were I writing this webapp with what I know now, I would make a single webapp that uses a database for user information, and a different database that contains all of the information of the resources that the user is able to access. Authentication and authorization would be handled using Acegi (of which I have a very limited understanding of). However, we also have other webapps that we would like to be able to access the same user login information. One way (the only way I know of) would be to have these other applications access the same user database and have all of the same Acegi configuration. Each webapp would have all of the configuration needed to allow users to login, manage their accounts, etc. The vast majority of this configuration would be duplicated for each webapp. It seems like a better way to handle this situation would be to have a single web service that deals just with user login and registration. Then any webapp that needs to have a user login would just redirect to this web service and get back some sort of User object. Each individual webapp would only need to configure Acegi for the specific resources that they provide. So my above example would look up the user in a database and present user specific resources. A webapp that allows a user to activate a product using a product key would just have a database to map a user to the products they have activated. So finally my questions (sorry for the long winded explanation): 1. Is this login web service something that is actually commonly used? 2. Is this what a web service actually is, or am I applying that term where it doesn't belong? 3. Is Acegi flexible enough to use in a setup like this? 4. Is there enough additional complexity in setting up a system like this that it would also make sense to look into just duplicating the configuration for each webapp? 5. Are there any good books, web tutorials, etc that talk about this? I guess what I'm basically looking for is a little design direction, possibly other technologies that provide these services so I'm not trying to build an entire system from scratch. Thanks in advance for your suggestions! Kelly -- View this message in context: http://www.nabble.com/-S2--Struts-with-Web-Services-tp16475805p16475805.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts with Web Services
Hi, 1. Is this login web service something that is actually commonly used? Yes and no, mainly because WS is session-less and you have to manage the session token by your self. We use such approach internally, through ssl and we manage session expirations by hand. 2. Is this what a web service actually is, or am I applying that term where it doesn't belong? In my opinion, if you don't have global SOA architecture / specification / whatever it can be what ever you want, but without clear path it can be mess in the near future. 3. Is Acegi flexible enough to use in a setup like this? I think yes, you can extend almost everything / re-implement all the classes and customize them to do what you want. 4. Is there enough additional complexity in setting up a system like this that it would also make sense to look into just duplicating the configuration for each webapp? If you will have common template / approach / guideline there be nothing more just to setup individual settings for each webapp. In other case, you will all the time invite the wheel. 5. Are there any good books, web tutorials, etc that talk about this? Google? IBM alfa works site ? ;-) I guess what I'm basically looking for is a little design direction, possibly other technologies that provide these services so I'm not trying to build an entire system from scratch. I thing you should start building your SOA strategy and how to fit it to your current projects / structure. It's better to thing twice. Regards -- Lukasz http://www.linkedin.com/in/lukaszlenart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Struts with Web Services
I see that Lukasz already has a longer response, but if I am reading your request properly, then I think you might be looking for CAS - http://www.ja-sig.org/products/cas/ -Wes On Thu, 2008-04-03 at 16:00 -0700, Kelly.Graus wrote: Hello, I've been spending the last couple months familiarizing myself with a few java based web technologies, mainly Struts 2, Spring, and Hibernate. I have a decent understanding of Struts, enough to make a few simple example webapps that have helped me learn the concepts (along with a lot of help from this message board!). I'm now trying to design a real webapp that does more than one simple task. The basic idea is that I want a single User database that contains login and registration information (user name, password, name, address, etc). When a user logs in, they are presented with a home page that shows them all of the resources they are able to access (things like product updates, product information, trial keys, etc). Were I writing this webapp with what I know now, I would make a single webapp that uses a database for user information, and a different database that contains all of the information of the resources that the user is able to access. Authentication and authorization would be handled using Acegi (of which I have a very limited understanding of). However, we also have other webapps that we would like to be able to access the same user login information. One way (the only way I know of) would be to have these other applications access the same user database and have all of the same Acegi configuration. Each webapp would have all of the configuration needed to allow users to login, manage their accounts, etc. The vast majority of this configuration would be duplicated for each webapp. It seems like a better way to handle this situation would be to have a single web service that deals just with user login and registration. Then any webapp that needs to have a user login would just redirect to this web service and get back some sort of User object. Each individual webapp would only need to configure Acegi for the specific resources that they provide. So my above example would look up the user in a database and present user specific resources. A webapp that allows a user to activate a product using a product key would just have a database to map a user to the products they have activated. So finally my questions (sorry for the long winded explanation): 1. Is this login web service something that is actually commonly used? 2. Is this what a web service actually is, or am I applying that term where it doesn't belong? 3. Is Acegi flexible enough to use in a setup like this? 4. Is there enough additional complexity in setting up a system like this that it would also make sense to look into just duplicating the configuration for each webapp? 5. Are there any good books, web tutorials, etc that talk about this? I guess what I'm basically looking for is a little design direction, possibly other technologies that provide these services so I'm not trying to build an entire system from scratch. Thanks in advance for your suggestions! Kelly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
