RESTful web service CAS authentication

Question

My application must access a RESTful web service running on another server. This web service uses CAS authentication, and when using it through a browser, it is redirected to CAS registration if the user has not yet been authenticated. There is no way to actually log in through CAS. My application also uses CAS so that users are authenticated

I would like to access it through JQuery / Ajax, but the server does not seem to be configured for JSONP, which, as I understand it, is necessary due to the cross-domain access problem.

Now I could make Ajax requests through my server, which leads to my question: without the CAS login method to call my server, how can I "tell" the web service that the user is authenticated?

So, I suppose, firstly, I want to understand what happens between the browser, CAS and the RESTful service, and how authorization is processed without any explicit transfer of credentials. Secondly, I want to see how / if I can replicate this when calling the service from my server - it will not be the same session as the request from the browser, therefore there will be no CAS authorization token, but I do not see how it receive or provide.

Answer 1

To question 1 about how authentication / single sign works:
When you log in to the CAS server (say security.example.com), you will set a cookie in your browser for the security.example.com domain. A typical stream when accessing protected files through a browser in an application using standard CAS authentication filters and authentication filters is as follows:

• The CAS authentication filter configured for the application checks to see if the user object is in the session. If yes, the user passes through
• If not, the CAS authentication filter redirects the browser to the CAS login page. In a scenario with a single icon, the CAS server recognizes its own cookie, checks if the application is registered and is participating in the same sign - if so, it redirects the browser back to the application with the service ticket.
• The CAS validation filter configured in the application identifies the service ticket and links the CAS server to validate the ticket and create an approval object

For the entire stream to work, you will need cookies and session processing.

To question 2 about how to handle server-side authentication:
We had a similar problem in our application and use two different ways to get around this:

• Use the internal user of the system and access the server to the server, passing the credentials of this user using the basic authentication headers. Of course, you need to have the appropriate filters configured to handle non-interactive login with basic authentication tokens. This is easy to implement, but has obvious drawbacks, such as having this special system user, an application that sees the user's password, etc.
• Use proxy authentication . In this approach, when your user is authenticated for application 1, it also generates a proxy ticket that will be used by application2 (from server to server call). This proxy ticket can be transmitted through server-to-server communication, so application 1 accesses application 2 on behalf of the user.

Answer 2

I use this setting in one of my projects. Some of the CAS implementations allow authorization through a call to rest. Try adding the main authorization header (Base 64 Encoding of Username and Password). it looks something like this.

Title ("Authorization", "Basic")

Also try accessing the REST API using Mozilla's REST Client for debugging purposes. It really helps you understand the various headings, etc.