Hi Dale, Thanks for your reply!
One issue I can see is that instead of entering SSO credentials into the CAS web ui, you are now entering SSO credentials into the "web service client". Scott's oft repeated view (I think) is that only entering creds into one server side application is an indispensible security advantage. Personally I think it is useful to be able to enter user credentials into *other client side applications besides browsers*, and the RESTful api is a useful enabler. But be warned that this is not considered a good practice. We do have the requirement to authenticate web services, and I can't really think of any other way to do that right now. But if there is another, potentially better way, I'd certainly be open to it. I'd really appreciate getting Scott's feedback on this. :) The disadvantage of your approach below is that now the TGT is exposed in the "web service client" space and in the pipe between the client and your "authentication web service". That's true. But isn't that the case when authenticating via the web browser as well, since the TGT is stored in the CAS cookie in the client's web browser? If we force the web service client to provide the username and password using SSL, isn't that essentially the same thing as authentication via the web browser? Or I am missing something? :) I also wonder why the "authentication web service" exists. Why not go straight to the restful api from the web service client? I don't think the authentication web service adds anything useful, but maybe I misunderstand. 1. A web service client sends the username and password to the CAS server via the RESTful API, and obtains a ticket granting ticket (TGT). 2. The RESTful API returns the TGT to the web service client. 3. The web service client sends the TGT and the name of a target web service to the RESTful API to obtain a single-use service ticket for the target web service. 4. The RESTful API returns the single-use service ticket to the web service client. 5.The web service client sends the single-use service ticket to the target web service, along with any other parameters. 6. The target web service sends the single-use service ticket and its name (which should match the target web service provided by the web service client when the service ticket was obtained) to the CAS server for validation. 7. If validation is successful, the CAS server returns the username associated with the single-use service ticket to the target web service. 8. Optional Step: The target web service checks if the user is authorized to execute the target web service. 9. If authentication (and optionally authorization) is successful, the target web service processes the web service client's request and returns the result to the client. Unfortunately, this Authentication Web Service is something that we need to maintain in our application for backwards compatibility. We basically have the requirement that any web service client code that works with the current version of the application *must* work with the new version of the application as well, without requiring *any* code changes to the web service client. However, even if this requirement wasn't there, I would still want to "hide" the authentication mechanism from clients. That is, I wouldn't want the client code to go directly to the CAS server because if we changed the authentication mechanism in the future to something other than CAS, that would require changes to the client code, and that's something we'd like to avoid. But I'm not sure I'd make it a separate web service, like it is now. As I mentioned above, that's there for backups compatibility. Thanks again for your comments, Pat Dale ________________________________ From: Guimaraes, Patricia (NIH/NLM) [C] [mailto:[email protected]] Sent: Thursday, 6 May 2010 2:28 a.m. To: [email protected] Subject: [cas-user] using CAS for web service authentication Based on what I've learned so far, it seems like using the RESTful API for web service authentication is a reasonable option. Since the target web services are part of our application, there is no need for proxying. Information about the RESTful API can be found at http://www.ja-sig.org/wiki/display/CASUM/RESTful+API. Below is how I plan to implement web service authentication within our application: 1. A web service client sends the username and password to an Authentication Web Service. 2. The Authentication Web Service sends the username and password to the CAS server via the RESTful API, and obtains a ticket granting ticket (TGT). 3. The Authentication Web Service returns the TGT to the web service client. 4. The web service client sends the TGT and the name of a target web service to the Authentication Web Service to obtain a single-use service ticket for the target web service. 5. The Authentication Web Service sends the TGT and the target web service to the CAS server and obtains a single-use service ticket for the target web service. 6. The Authentication Web Service returns the single-use service ticket to the web service client. 7. The web service client sends the single-use service ticket to the target web service, along with any other parameters. 8. The target web service sends the single-use service ticket and its name (which should match the target web service provided by the web service client when the service ticket was obtained) to the CAS server for validation. 9. If validation is successful, the CAS server returns the username associated with the single-use service ticket to the target web service. 10. Optional Step: The target web service checks if the user is authorized to execute the target web service. 11. If authentication (and optionally authorization) is successful, the target web service processes the web service client's request and returns the result to the client. If anyone thinks that this implementation would be insecure, please let me know. Thanks a lot, Pat -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
