[MNT-15500] CLONE - CMIS login loop when using Kerberos SSO Created: 14-Jan-16  Updated: 11-Mar-18  Resolved: 28-Apr-16

Status: Closed
Project: Service Packs and Hot Fixes
Component/s: Repository Authentication and SSO
Affects Version/s: 5.0.2
Fix Version/s: None

Type: Bug
Reporter: Kevin Roast [X] (Inactive) Assignee: Closed Issues
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 weeks, 1 day, 4 hours
Original Estimate: Not Specified

Issue Links:
Cloners
is clone of ALF-21521 CMIS login loop when using Kerberos SSO Closed
Duplicate
is duplicated by ALF-21537 Problem with SSO and CMIS Closed
is duplicated by MNT-14718 Problem with Passthru, NTLM, SSO and ... Closed
Related
is related to by ALF-21983 (Again) no fallback to basic auth for... Resolved
is related to by MNT-16232 Share cannot be configured to use bot... Closed
Bug Priority:
Category 2
Regression Since:
5.0
Cloud or Enterprise: Enterprise Only

 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.

 Comments   
Comment by Cristian Turlica [ 21-Jan-16 ]

Replicated the issue as described on:

  • Alfresco Community v5.0.0 (d r99759-b2) schema 8022 using the provided authentication chain.
  • Alfresco v5.0.N (latest build) schema 8022 using the provided authentication chain. The interesting thing is that on this version the reporter's workaround doesn't work, having the same endless loop. Investigation doesn't seem to provide a cause...
Comment by Cristian Turlica [ 09-Feb-16 ]

The last time this worked as the original reporter requested was on Alfresco Community 50b , this was a pre-release version of 5.0.0 so it never worked in 5.0.N releases.
The Comunity 50b was originated from /alfresco/BRANCHES/DEV/HEAD-BUG-FIX @revision r86468. Because the changes from this revision to the first release are extensive , it will take some time before we find and fix the cause. Will continue to do iteration checks and tests to see if we can narrow the scope of the search for the root cause.

Comment by Richard Esplin [X] (Inactive) [ 10-Mar-16 ]

Linking in issues that external developers tell me are related. It is reproduced on 5.1.e.

Comment by Kevin Roast [X] (Inactive) [ 27-Apr-16 ]

OK after discussions with Cristian and Gary, the conclusion for now is "Won't Fix" - and supply a work-around for this use-case.

Why?

  • The use-case described in the original 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 should not attempt to change 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.

Comment by Richard Esplin [X] (Inactive) [ 11-Mar-18 ]

See ALF-21521 and ALF-21983 for discussion on why we didn't change this behavior.

Generated at Fri Apr 23 11:32:17 BST 2021 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.