Uploaded image for project: 'Alfresco'
  1. Alfresco
  2. ALF-21521

CMIS login loop when using Kerberos SSO

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: 5.0.d Community
    • Fix Version/s: None
    • Security Level: external (External user)
    • Labels:
      None
    • Regression:
      Regression

      Description

      I have set up v5.0d Community with Kerberos authentication and I am having issues with the CMIS api.
      This only happens on boxes that don't get Kerberos Authentication (e.g. Linux desktops) and it falls through to LDAP. If the Kerberos succeeds, then the CMIS auth succeeds.
      If I go to:
      /alfresco/api/default/public/cmis/versions/1.0/atom
      I get an endless loop of a page with a link to "log in". I can make this go away by first visiting:
      /alfresco/webdav/
      where I get a correct login popup. After entering my credentials I am able to get the atom page to give me an atom.
      I have another box with v5.0b which works correctly and pops up a request for credentials when I go to the atom page. Therefore I believe it to be a regression from v5.0b.

        Attachments

          Issue Links

            Activity

            Hide
            kroast Kevin Roast [X] (Inactive) added a comment -

            MNT-15854 was commented as "Accidental clone". Apologies for confusion related to that.

            MNT-14367 is shown as fixed, and should have been merged to HEAD well before 5.1 release.

            Please retest with 5.1.e latest Community release. If it is not fixed there then we still have a bug, otherwise this will be closed as fixed in 5.1.

            Thanks!

            Show
            kroast Kevin Roast [X] (Inactive) added a comment - MNT-15854 was commented as "Accidental clone". Apologies for confusion related to that. MNT-14367 is shown as fixed, and should have been merged to HEAD well before 5.1 release. Please retest with 5.1.e latest Community release. If it is not fixed there then we still have a bug, otherwise this will be closed as fixed in 5.1. Thanks!
            Hide
            kroast Kevin Roast [X] (Inactive) added a comment -

            Various internal discussions and investigations have been performed around this issue. The conclusion for now is "Won't Fix" - and supply a work-around for this use-case.

            Why?
            The use-case described in the ticket was effectively blocked in 5.0.1 with the changes in MNT-12765. This case was really a "back door" to using multiple authentication stacks (a main alfresco one and the one that the CMIS /api endpoint allowed) which was insecure. The changes in MNT-12765 ensure that all service API endpoints for the Alfresco web-app use a consistent authentication stack - this was required for Share and to make the application more secure.

            We believe that we should not restore this behaviour for the use-case as detailed in the original ticket. It will reopen that back door to CMIS and make the application less secure - even when highly secure Kerberos authentication stack is used, it would have been possible to use http basic auth for CMIS API etc.

            The work-around is quite simple. Remove the /api endpoint from the auth filter i.e. remove this section from alfresco WEB-INF/web.xml:

               <filter-mapping>
                  <filter-name>Global Authentication Filter</filter-name>
                  <url-pattern>/api/*</url-pattern>
               </filter-mapping>
            

            This will restore the behaviour where the /api endpoint will support basic auth and not be wrapped in the more secure alfresco authentication chain filter.

            Show
            kroast Kevin Roast [X] (Inactive) added a comment - Various internal discussions and investigations have been performed around this issue. The conclusion for now is "Won't Fix" - and supply a work-around for this use-case. Why? The use-case described in the ticket was effectively blocked in 5.0.1 with the changes in MNT-12765. This case was really a "back door" to using multiple authentication stacks (a main alfresco one and the one that the CMIS /api endpoint allowed) which was insecure. The changes in MNT-12765 ensure that all service API endpoints for the Alfresco web-app use a consistent authentication stack - this was required for Share and to make the application more secure. We believe that we should not restore this behaviour for the use-case as detailed in the original ticket. It will reopen that back door to CMIS and make the application less secure - even when highly secure Kerberos authentication stack is used, it would have been possible to use http basic auth for CMIS API etc. The work-around is quite simple. Remove the /api endpoint from the auth filter i.e. remove this section from alfresco WEB-INF/web.xml: <filter-mapping> <filter-name>Global Authentication Filter</filter-name> <url-pattern>/api/*</url-pattern> </filter-mapping> This will restore the behaviour where the /api endpoint will support basic auth and not be wrapped in the more secure alfresco authentication chain filter.
            Hide
            rich.bade Richard Bade added a comment -

            Hi Kevin, thanks for looking into this and for the work-around. I can confirm that this work-around resolves my issue in 5.0d and is acceptable in my situation.

            Show
            rich.bade Richard Bade added a comment - Hi Kevin, thanks for looking into this and for the work-around. I can confirm that this work-around resolves my issue in 5.0d and is acceptable in my situation.
            Hide
            loftux Peter Löfgren added a comment -

            The referenced issue MNT-12765 cannot be viewed so it is hard to assess exactly what security loop hole I would open up by using the proposed workaround. Can you please open or post the full details here?

            Show
            loftux Peter Löfgren added a comment - The referenced issue MNT-12765 cannot be viewed so it is hard to assess exactly what security loop hole I would open up by using the proposed workaround. Can you please open or post the full details here?
            Hide
            kroast Kevin Roast [X] (Inactive) added a comment -

            Hi Peter. The work-around means that basic auth can be used on the /api endpoint - even if you have Kerberos etc. securing the rest of Alfresco such as /service endpoint. I don't believe you should consider it a security hole if you were using it safely before. We believe that having a single authentication stack securing all REST API endpoints is more secure, even if it is less flexible.

            Show
            kroast Kevin Roast [X] (Inactive) added a comment - Hi Peter. The work-around means that basic auth can be used on the /api endpoint - even if you have Kerberos etc. securing the rest of Alfresco such as /service endpoint. I don't believe you should consider it a security hole if you were using it safely before. We believe that having a single authentication stack securing all REST API endpoints is more secure, even if it is less flexible.

              People

              • Assignee:
                closedissues Closed Issues
                Reporter:
                rich.bade Richard Bade
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Date of First Response: