Doucmentum 6.7 CMIS SSO

We're looking at developing a CMIS based application that integrates with both Sharepoint 2010 and Documentum. A requirement is to support single sign on (SSO) using kerberos. We have proven this with Sharepoint 2010, but Documentum is a new area for us, and we're having difficulties determining whether a) it is possible and b) how it is achieved.

Any input greatly received.

Alan.

Find more posts tagged with

Comments

DCTM_Guru

This is supported in 6.7. Read the content server admin guide for more details.

aborland

Thanks for this, I've now setup kerberos support as described in the CS admin guide. However, the CMIS reference guide only mentions the WS-Security UsernameToken profile which requires a 'user name' and 'password' field to be supplied, something we don't want to do. When I connect to Sharepoint CMIS I'm using Windows authentication, which I've assumed includes the kerberos ticket. Attempting the same connection method against Documentum throws an exception "Authentication failed due to missing credentials [com.emc.documentum.fs.cmis.impl.dfs.exception.AuthenticationException] null". As the CMIS reference guide only describes the Username Token profile I'm wondering whether I'm attempting something which isn't possible?

Thanks,

Alan

peter.rowland99

Johnny/All - can you point me to any documention for confguring the CMIS stack for SSO please ? ... the document "EMC Doumentum Kerberos SSO Authentication" seems only to reference DFS and WebTop, and the WCF reference is 'limited'.

Any pointers Welcome.

Thanks

bacham2

I don't think that the Documentum implementation of CMIS provides any support for Kerberos (at least I couldn't find anything in the documentation). However, you should be able to pass a Kerberos token in the security header instead of the password. The trick is to tell the Content Server that it is a Kerberos token, so that it uses the Kerberos plugin (dm_krb) to authenticate the request. Here's how I would do it:

1. Retrieve a Kerberos for the Documentum service from the KDC (as configured for your Content Server).

2. Encode the Kerberos using base64

3. Add the following prefix to the base64-encoded token: DM_PLUGIN=dm_krb/

4. Insert the string above instead of the password in the WS Security header of the CMIS request

I haven't tried it but it should work.

abc123

Kerberos SSO support for CMIS is in schedule of Documentum 7.0, for both WS SOAP Binding and AtomPub RESTful Binding. Some customers tried DFS Kerberos configuration on CMIS and it worked, but it leaves you to address the potential technical issues.

Regards,

William

bacham2

Thanks for the information William! That's good news!

Are there any plans to include principal authentication to CMIS like for Webtop/TaskSpace? For most customers, this would be the simplest solution since they already authenticate users at the App Server layer (typically SSO based on Kerberos or another method). The CMIS webapp could then simply retrieve the user identity and get a session on behalf of the user.

abc123

Hi bacham2,

That's a good suggestion. We had internally discussed and experimented container based authentication for CMIS, but due to non-tech reasons, it is NOT put on plan yet. Customer voice is the strong drive for us to determine to add a new feature. You are welcome to raise this feature request to CMIS product manager.

Thanks,

William

DCTM_Guru

To Williams point, you need to submit feature request via EMC support in order for this to be tracked by product manager.

bacham2

I just tried to use a Kerberos ticket to login via CMIS using the technique I mentioned in my previous post. While the initial login works, it seems like Documentum CMIS tries to reuse the token multiple times (i.e. for subsequent requests) which fails (rightly so because it is considered a replay).

I used Apache Chemistry OpenCMIS for the CMIS calls from my Java client. While it's possible that the culprit is OpenCMIS (sending the Kerberos token multiple times), I suspect that the issue is with Documentum CMIS.

@William: can you confirm?

abc123

Hi bacham2,

On client side, you need to issue a new service ticket for each CMIS request. Please check whether it works as expected, for instance, examining the request via a http proxy tool.

Then on server side, you need to write a Kerberos server handler (for WS) or filter (for RS), which accepts the ticket, obtains the delegated TGT, and sets to DFS BinaryIdentity. The underlying DFS/DFC will issue new Content Server tickets each time.

The problem probably exists on the client or server Kerberos handler, not inside CMIS.

Regards,

William

bacham2

Hi William,

Unfortunately, requesting a Kerberos ticket for each CMIS request is not scalable. If every application did that, the Active Directory KDC would go on its knees. AD administrators at most companies will not accept that.

With DFS or Webtop, this is not how it works. A kerberos ticket must only be retrieved once.On the app server-side, as long as the DFC session that originally used the ticket is not closed, it is not necessary to request another Kerberos ticket (even if the session times out on the Content Server side). Obviously, we don't have much control over how Documentum CMIS manages DFC sessions, so I guess I will not use Kerberos for the moment.

Hicham

abc123

Hi Hicham,

The ticket I was referring is Kerberos Service Ticket (service credential) for SPN, which should be renewed every time. This is required by Kerberos V5 to resist replay attack. On both client & server side, the Kerberos Ticket Granted Ticket (client credential) surely can be cached for reuse.

Regards,

William

bacham2

Hi William,

I know that you were talking about the service ticket not the TGT.

An application that supports Kerberos should typically not request a service ticket for every application request. While you are correct that a the service ticket can only be used once, a JEE app would typically authenticate the user once and then send back some sort of session ID in the form of a cookie. Subsequent requests would therefore not require additional Kerberos service tickets. That's how it works in Webtop for example. And that's how I would expect a CMIS implementation to work.

Again, at most companies I worked at the Active Directory responsible would not be happy at all if applications would pound the KDC for each and every single application request. This simply doesn't scale!

Hicham