Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-1017

Add toggle to turn off checking of remote-ip in Validation Factors

    XMLWordPrintable

Details

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    Description

      Crowd currently uses remote-ip and X-Forwarded-For in the crowd.token validation factors. This is of course the appropriate default behavior. By binding a cookie.token to the client machine you prevent stolen cookies being useful.

      However, there are some circumstances where you are willing to relax ip-binding check in order to achieve other goals, or to operate within other constraints. Examples are:

      • large proxying firewalls where requests from the same browser might be served by different proxy ip addresses. This is not uncommon in large corporate environments.
      • you are trying to achieve SSO between two crowd-enabled apps, where one app is behind Apache using AJP13 and the other is using HTTP ProxyPass. In this environment, AJP13 puts the correct remote-ip in the validation factors, where as ProxyPass puts the incorrect remote ip but a suitable X-Forwarded-For. This makes the validation factors incompatible and makes SSO unachievable. (This point relates to CWD-541.)
      • you have users with mobile devices (laptops, those funny iPhone thingies) where moving between wifi access points, or moving from work to home, means a different IP and an invalid crowd.token. It would be nice to enable "remote ip check-less" or "mobile" mode for these users.

      What I would like to see is a checkbox for disabling "use remote IP as a validation factor". This would cause Crowd to ignore remote-ip and X-Forwarded-For when looking at validation factors. I'm not sure where this checkbox would go, some combination of these?

      • globally?
      • per directory?
      • per application?
      • per user (or group of users)?

      The default behavior of this checkbox should definitely, of course, be enabled. But I think there is a case where users may want to knowingly disable it in order to achieve SSO in their environment.

      Attachments

        Issue Links

          Activity

            People

              jwalton joe
              mquail Matt Quail (Inactive)
              Votes:
              11 Vote for this issue
              Watchers:
              27 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 32h Original Estimate - 32h
                  32h
                  Remaining:
                  Remaining Estimate - 32h
                  32h
                  Logged:
                  Remaining Estimate - 32h
                  13m