以CAS和SAML2 SSO为例

Question

We have about a dozen internal admin web apps (mostly Java) that employees use for various workflows, and each of them have their own, disparate sign-in/authentication systems. I've been asked to federate them all together under a single sing-on system. I was handed the following diagram to use as a starting point:

As you can see, each app uses a CAS client to connect to a CAS server. This server also has Apache httpd with a Shibboleth plugin (?) configured. This CAS server then communicates with our Active Directory ("AD") server.

I need to make sure I completely understand how these technologies all work together:

• What is happening between the CAS server and Apache/Shibboleth?
• What is happening between Apache/Shibboleth and the "Trust Store"?
• What is being communicated between the CAS server and AD?
• What is stored in this SAML2 token being sent back from the CAS server to each CAS client?
• How can I, as a Java developer, do with the SAML2 token (or lack thereof if auth fails) to actually sign users in with?
• Are there any better technology choices here: if so what are they, and why? Bear in mind that all of these are Java apps, except one of them, which is a C#.NET app.

Answer 1

Here are a few of your answers:

First, let me give you a quick overview of how the interaction between a CAS client and a CAS server normally works: (I am not familiar with the Shibboleth portion, so I am omitting that.)

1. User hits the application webpage.
2. application redirects user to CAS.
3. CAS, using standard cookies and sessions, determines if user is already logged in.
4. if User is not logged in, CAS displays a login form for the user to provide login credentials. IF the user is already logged in, CAS skips to step #7.
5. CAS then interacts with the AD to verify that the provided credentials are valid.
6. if they are, then CAS logs in the user.
7. then CAS will redirect back to the application, providing a ticket.
8. The application makes a direct call to CAS to validate the provided ticket.
9. If the ticket is valid, then CAS returns user information as a response to the request.
10. The application then creates an authenticated session for the user, potentially looking up user information based on the info provided by CAS, and redirects them wherever is appropriate.

Now for your questions:

• CAS and AD : CAS will actually login to AD and use the user provided credentials to find and authenticate the user. If you are using a forest, make sure you use the correct port to log into the Global Catalog, as that is easy to miss.
• The contents of the token are not significant, as the standard CAS protocol will send the token back to CAS and retrieve user details in the response.
• As a developer, this is actually very little you can do with the token, as it is tied to the application and can only be used once, and, for security reasons, has to be used within a very short amount of time (ie, sent back to CAS to be validated) or it will expire.

If you are doing primarily CAS and you have the ability to do your own CAS clients in your applications, CAS can be a very nice solution. Unfortunately, CAS does not have full SAML2 support, using it's own protocol instead, though CAS's protocol is very similar to the ARTIFACT profile for SAML2. If you want to integrate with other SAML2 clients, some work needs to be done.

Also, if your java applications happen to use Spring, Spring security includes a CAS client out of the box.

It is also pretty easy to write a custom client as you can see that the protocol is not terribly complex.

Also, while it is a bit more work and can be a pain to set up, if your employees already login to your domain via windows, then you can actually piggy back on that and configure CAS to use the windows login information users have already provided rather than prompting users with a login form making them re-enter their windows credentials.