Announcement Announcement Module
Collapse
No announcement yet.
Authorize on two or more web applications simultaneously Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    No you are still missing the point... You authenticate in app1 and CAS issues a ticket you don't get it from JNDI or Databse you get it AFTER you have authenticated from CAS... (I suggest a read of the CAS guide and what you can do). Also I suggest the book Spring Security 3 (an upgrade is pending) which explains CAS nicely.

    And yes spring security (when configured correctly) should support this.

    Comment


    • #17
      Marten, I understand that I'm bothering you by (maybe stupid) questions, but.

      All the literature you'd mentioned relies on two assumptions:
      1. I can only authenticate user at ONE application at time.
      2. Application has some magic point named "Secured page", that triggers authorization process.

      Neither are true in my case. That's the reason, why I am looking for suitable solution and asking those questions.

      I have no secured pages (or, by another words, all my pages are secured at the same level - anyone_can_read), and I want to know, "who is here" on every page. So I see only two solutions:
      - to trigger authentication process on every page (very expensive with CAS);
      - to share by some way credentials (or tickets, or SSO_COOKIE etc) among my applications at the authentication time.

      I am looking for latter.

      Comment


      • #18
        The problem is you don't understand spring security...

        The authentication process is only triggered once for each application, upon entering the application. If you aren't authenticated the first application you enter will show the CAS loging page, CAS authenticates and authorizes the user and it gives the user a Ticket. After the authentication spring security creates a SecurityContext and stores this in the session, the ticket is stored in a (at least should) be stored in a server-wide cookie.

        Now when you enter the second application, the ticket is send to CAS which verifies it and when that succeeds again a SecurityContext is created and stored in the session.

        So as I mentioned before your logic is flawed, spring is taking care of the authorization CAS is only for authentication NOT authorization!.

        Comment


        • #19
          Originally posted by Marten Deinum View Post
          The authentication process is only triggered once for each application, upon entering the application. If you aren't authenticated the first application you enter will show the CAS loging page
          It's not a valid use case for me. Imagine a forum as first application, for example. Anyone can read it, doesn't matter, is [s]he registered at all. There is no "Secure resources" on this hypothetical forum. When should I trigger a CAS authentication process?

          Originally posted by Marten Deinum View Post
          the ticket is stored in a (at least should) be stored in a server-wide cookie.
          Do you mean "CAS server-wide" or "applications server-wide"? On some examples, as I can see, there are no server-wide cookies at all. Just application-scoped.
          Last edited by Lsync; Oct 4th, 2012, 09:39 AM.

          Comment


          • #20
            If you don't have a page which requires authorization it is also pretty useless to display a username if someone isn't logged in imho.. That isn't a problem related to CAS but more on how you structured your application...

            Regarding CAS I give up, I suggest google and the official documentation...

            Comment


            • #21
              Marten, thank you for help anyway.

              Comment


              • #22
                A possible solution

                I came up with a solution.

                Full sample project is here.

                I've decided not to use remember-me and not to intrude to SSO workflow (like CAS tickets storing). It works like this:
                1. While user browses non-protected applications pages, there is no CAS requests at all, doesn't matter if such user is authenticated or not at the moment.
                2. When user authenticates by any application, this application sets domain-wide "Authenticated=true" cookie.
                3. When any other application sees this cookie, it starts standard authentication process, does not matter if a protected or unprotecred page is requested.

                To let this approach work just two classes needed: GroupAuthenticationFilter to set the cookie when needed, and GroupAuthLogoutHandler to delete this cookie when user logs out. Both are quite simple.

                No security risks, no EARs needed, and it should work with any authenticators, both internal and external types. Now (at last!) I can render user name on any site page, and make a group authentication.

                Not the best possible solution, but I hope this help to someone else. Feedbacks are very welcome.

                Comment


                • #23
                  Yet another solution, if anyone is interested.

                  We can proxy all requests thru any of applications on the same server. This approach gives us a full-fledged shared sessions, not a simultaneous authentication/authorization only.

                  A working example is here.

                  Warning! Shared sessions can be potentially dangerous.

                  Comment

                  Working...
                  X