chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suhaib Fahad <fahad.suh...@pogeyan.com>
Subject Re: OpenCMIS SSO authentication provider
Date Tue, 30 Oct 2018 08:31:52 GMT
Hi, I guess SSO is outside the CMIS context, what we have done is validate the TOKEN that gets
generated by SSO in CMIS to validate if the login is valid or not. And for this to work with
OpenCMIS server, you could just add a Filter for that.

Cheers,
Fahad
 

On 30/10/18, 2:49 AM, "Lu, Wentao" <Wentao.Lu@bchydro.com> wrote:

    Hi Florian,
    
    Thanks for the detail.   I think there is no problem for extract the data in the CallContextHandler.
 The question is where we do the authentication in OpenCMIS Server Framework, is the getService()
in service factory a good place to do the customized authentication?
    
    
    Thanks
    Wentao
    
    -----Original Message-----
    From: Florian Müller [mailto:fmui@apache.org] 
    Sent: Monday, October 29, 2018 1:43 AM
    To: dev@chemistry.apache.org
    Cc: Lu, Wentao
    Subject: Re: OpenCMIS SSO authentication provider
    
    Hi Wentao,
    
    build a servlet filter in front of the OpenCMIS bridge that handles the 
    authentication. You should be able to trigger the authentication 
    mechanisms of the application server there, if you need that.
    In that filter, stick all data about the user you need in the bridge 
    into request attributes. Now you are free to use that data in the 
    CallContextHandler, the service factory, or in each call.
    
    The OpenCMIS server framework only supports basic auth and there is 
    nothing else planned.
    
    
    - Florian
    
    
    > Thanks Florian.
    > 
    > We use CMIS bridge here, the transaction flow is :  client
    > (Jboss)->cmis-bridge(weblogic)->FileNet CMIS server(weblogic).
    > Usually we ask client to set a http basic header when call
    > cmis-bridge, this time we'd like to looking for SSO solution, I expect
    > client can send cmis-bridge an authentication token (Kerberos or SAML,
    > etc.) and cmis-bridge will accept and proceed it.
    > 
    > I guess this is server side use case. My understanding is we need to
    > build a customized CallContextHandler, could you help to provide some
    > ideas or guidelines and sample code if possible?
    > 
    > Does cmis-bridge support application server authentication?  WebLogic
    > supports both Kerberos and SAML and also FileNet CMIS server supports
    > application server authentication.
    > 
    > Thanks
    > Wentao
    > 
    > -----Original Message-----
    > From: Florian Müller [mailto:fmui@apache.org]
    > Sent: Friday, October 26, 2018 3:25 AM
    > To: dev@chemistry.apache.org
    > Cc: Lu, Wentao
    > Subject: Re: OpenCMIS SSO authentication provider
    > 
    > Hi Wentao,
    > 
    > Are you talking about the client side or the server side?
    > 
    > On the client side, there is support for basic auth, NTLM (with many
    > restrictions), OAuth, and client certificates. Kerberos is supported 
    > (to
    > some degree) by the JVM. SAML doesn’t make sense here. Other
    > authentication mechanisms can be plugged in but are not provided
    > out-of-the-box.
    > 
    > On the server side, there is just basic auth support. Other
    > authentication mechanisms can be put in front of OpenCMIS. At SAP, we
    > have a product that works with basic auth, OAuth, SAML, and client
    > certificate authentication. So, it's doable but not provided by
    > OpenCMIS.
    > 
    > 
    > - Florian
    > 
    > 
    >> Could someone let me know what's the roadmap for Chemistry SSO
    >> support?  Is there any SSO (i.e. Kerberos, SAML, or others)
    >> authentication provider already or is planning to added into the new
    >> Chemistry release?
    >> 
    >> We have a coming project which prefer to use Kerberos or SAML for
    >> authentication via AtomPub/Java.
    >> 
    >> Thanks
    >> Wentao
    >> ________________________________
    >> This email and its attachments are intended solely for the personal
    >> use of the individual or entity named above. Any use of this
    >> communication by an unintended recipient is strictly prohibited. If
    >> you have received this email in error, any publication, use,
    >> reproduction, disclosure or dissemination of its contents is strictly
    >> prohibited. Please immediately delete this message and its attachments
    >> from your computer and servers. We would also appreciate if you would
    >> contact us by a collect call or return email to notify us of this
    >> error. Thank you for your cooperation.
    >> -BCHydroDisclaimerID5.2.8.1541
    

Mime
View raw message