cancel
Showing results for 
Search instead for 
Did you mean: 

Constrained Delegation w/ Kerberos and the double hop problem

arbitraryname
Champ in-the-making
Champ in-the-making
Hello,

I am evaluating Alfresco as a possible solution to our CMS needs and really think that it is the solution. A previous CMS we tried to use gave us absolute fits when we tried to implement SSO and I wanted to ask if some of our pain points are going to crop up.


Our ultimate goal is to rely on our underlying CMS' ACLs to control all data access, and leverage user impersonation/delegation throughout our environment to handle all our actions. EDIT: We also are planning to rely on the CMIS services. Will that constrain our options in anyway?

Our technology stack is mostly Java, however, we run in an environment that uses Active Directory and are forced to use constrained delegation. This gave us lots of problems because our last CMS platform could not handle that configuration.

Does Alfresco have any issues with constrained delegation that are known?


We also would like to be able to actually do the impersonation/delegation throughout all parts of our system. In our desktop and web client's we are fairly confident we can achieve this, but we are cautious to believe we can do that from inside alfresco reaching out to our web services.

Has anyone done that? Impersonated the authenticated user from within some custom features of Alfresco while calling remote services?


First off apologies if any of this is repeated or a series of novice questions. We are also open to other options like CAS, which I see is supported, but honestly our #1 goal is to use Kerberos. Thank you everyone!

Edit: I am having trouble with the Tags; sorry.
3 REPLIES 3

afaust
Legendary Innovator
Legendary Innovator
Hello,

due to the dual layer architecture of Alfresco with Alfresco Share as a UI web application and the Alfresco Repository as a separate service layer web application, Alfresco supports some use of delegated Kerberos tickets out of the box - Alfresco Share has to delegate the user identity to the backend Alfresco Repository.

The mechanism to handle Kerberos is actually "out-sourced" to the standard JAAS (Java Authentication and Authorization Service) facilities, so every Kerberos aspect that is supported by JAAS should be supported by Alfresco as well. Unfortunately, when using Dr. Google, I did not (yet) find positive confirmation for "constrained delegation". It is not listed in the <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-features.html">features added to Java GSS over the various releases</a> and a StackOverflow discussion suggested it may only be supported by commercial 3rd party Java libraries for Kerberos.
So, the problem is really a matter of "What is supported by Java" rather than "What is supported by Alfresco".

For calls from Alfresco to other web services in your infrastructure, you should be in full control of that since any such calls would have to be custom development by yourself. By default, Alfresco does not call other system except if they are part of the core configuration (content storage, authentication / user directory, transformation, search).

Regarding CMIS: There have been some issues in the past with side effects to CMIS if Kerberos is enabled. But apart from those (valid) bugs which either have been addressed already or are being addressed, CMIS should work with Kerberos. I must admit though, that I have only tested CMIS with Kerberos authentication in practice without full SSO activated.

Regards
Axel

arbitraryname
Champ in-the-making
Champ in-the-making
Apologies for taking so long to get back. We were doing a lot of investigation on our side.

Ultimately we have chosen to not use Kerberos to start. It seems like constrained delegation is not supported in Java until Java 8. (Look for S4U and read about its nuances to really find it if you are searching)



Anyway, now we are looking at alternatives and really wondering what to do. Our architecture is to have a few layers. A web app, and a thick client but all of that will funnel back to an intermediate web service which will ultimately call our Alfresco instance.

Our goal is create an environment where all of our calls run as the Customer/User clicking the button. We see in the documentation there is some support for an account to add a header variable to inform Alfresco what user to actually run this operation as. We for see this being able to satisfy our needs, but are there any known limitations to that? Things like "that won't work with Apache Chemistry" or Activiti contexts?

Do you even know that or should I create a new post? For reference I am talking about this: http://docs.alfresco.com/4.1/concepts/auth-external-props.html

afaust
Legendary Innovator
Legendary Innovator
Hello,

since you would only call the Activiti instances via the Alfresco ReSTful API (web scripts), external authentication typically work alright. Keep in mind that external authentication affects /alfresco/wcservice and /alfresco/wcs, not /alfresco/service or /alfresco/s. It should work for the Public API ReST interface as well, but I have not yet tried it.

For the CMIS API there have been some JIRA tickets of late concerning SSO scenarios that might affect external authentication as well. Generally speaking, it is supposed to work if the CMIS client provides the appropriate HTTP headers (or headers are added by a transparent authentication layer in between).

Regards
Axel