We support SSO today.  The SSO method that we support is the LTPA token in
the http header which is handled automatically by the Websphere container
where our CMIS service is running.
This is a standard way of handling this and it seems like the viewer should
support this as well.

Do we know for certain that the viewer can not support this?

Bottom line as we ship today. For SSO to work the client needs to include
that standard HTTP header (cookie) with the LTPA token.  (or do basic HTTP
auth, which again uses HTTP headers)

Putting it in the url would be non-standard (at least not part of the CMIS
spec) so I am reaching for a way to avoid this.

Jay Brown
Senior Engineer, ECM Development
IBM Software Group
jay.br...@us.ibm.com
www.linkedin.com/in/parityerror/


|------------>
| From:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Tim Webster <tim.webs...@gmail.com>                                          
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |"dev@chemistry.apache.org" <dev@chemistry.apache.org>                        
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |08/28/2014 09:36 AM                                                          
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: IBM FileNet P8 CMIS URL addressability + Daeja ViewOne Viewer            
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|





Hi,

Do you mean 'Would you want the client to request the *URL* with an extra
extension parameter..."?

I'll be retrieving the URL with this (straight from your book):

        if (session.getBinding().getObjectService() instanceof LinkAccess)
{
            return ((LinkAccess)
session.getBinding().getObjectService()).loadContentLink
(session.getRepositoryInfo()
                    .getId(), document.getId());
        }

If that URL had the token, great - if not and we had to do something extra
(like add it ourselves somehow), still OK.  The main thing is that the
repository can actually use a URL with the token in it.

Another thing occurred to me - would some kind of Single-sign on make all
this 'just work' (including the viewer)?  Apologies that I keep mentioning
the viewer, but it's the main problem here!

Thanks,

Tim



On Thu, Aug 28, 2014 at 5:10 PM, Jay Brown <jay.br...@us.ibm.com> wrote:

> No we don't currently support this but I am just trying to think this
> through from a security perspective if we wanted to add a feature.
> We can't include the user's security token in all of the returned stream
> url's by default. I would have to be requested.
>
> Would you want the client to request the document with an extra extension
> parameter indicating that the stream url should be returned with the
> current users LTPA token embedded? (includeAuthToken=true)
>
>
> Jay Brown
> Senior Engineer, ECM Development
> IBM Software Group
> jay.br...@us.ibm.com
> www.linkedin.com/in/parityerror/
>
> [image: Inactive hide details for Tim Webster ---08/28/2014 02:37:16
> AM---Jay, I've re-read your email, and I think I misunderstood wha]Tim
> Webster ---08/28/2014 02:37:16 AM---Jay, I've re-read your email, and I
> think I misunderstood what you were saying...
>
>
>
>    From:
>
>
> Tim Webster <tim.webs...@gmail.com>
>
>    To:
>
>
> "dev@chemistry.apache.org" <dev@chemistry.apache.org>
>
>    Date:
>
>
> 08/28/2014 02:37 AM
>
>    Subject:
>
>
> Re: IBM FileNet P8 CMIS URL addressability + Daeja ViewOne Viewer
> ------------------------------
>
>
>
> Jay,
>
> I've re-read your email, and I think I misunderstood what you were
> saying...
>
> *"We currently only support LTPA tokens with the FileNet CMIS server.
So
>
> if your client adds a 'Cookie' header with a value of a valid LTPA token
> (for the domain where the CMIS and CE server reside)  your request will
> succeed without a challenge for credentials. "*
>
>
> This is fine if we were actually constructing the HTTP request ourselves,
> but we're not - the Daeja ViewOne applet is doing it.
>
> *"...would you need us to support the passing of the token as a parameter
> in the Content stream URL?"*
>
>
> This would in fact help - if the content stream URL contained the token,
I
> could just pass that URL to the applet and it can do the rest.  As it is,
> does P8 support any URL of this type to retrieve content?
>
> Thanks,
>
> Tim
>
>
>
>
> On Wed, Aug 27, 2014 at 6:26 PM, Jay Brown <jay.br...@us.ibm.com> wrote:
>
> > We currently only support LTPA tokens with the FileNet CMIS server.
So
> > if your client adds a 'Cookie' header with a value of a valid LTPA
token
> > (for the domain where the CMIS and CE server reside)  your request will
> > succeed without a challenge for credentials.
> >
> > Does this help you or would you need us to support the passing of the
> > token as a parameter in the Content stream URL?
> >
> >
> > Jay Brown
> > ECM Development, IBM
> >
> >
> > [image: Inactive hide details for Tim Webster ---08/27/2014 03:36:11
> > AM---Hi, I'm looking to stream documents to the Daeja ViewOne View]Tim
> > Webster ---08/27/2014 03:36:11 AM---Hi, I'm looking to stream documents
> to
> > the Daeja ViewOne Viewer applet using a
> >
> >
> >
> >    From:
> >
> >
> > Tim Webster <tim.webs...@gmail.com>
> >
> >    To:
> >
> >
> > "dev@chemistry.apache.org" <dev@chemistry.apache.org>
> >
> >    Date:
> >
> >
> > 08/27/2014 03:36 AM
> >
> >    Subject:
>
> >
> >
> > IBM FileNet P8 CMIS URL addressability + Daeja ViewOne Viewer
> > ------------------------------
>
> >
> >
> >
> > Hi,
> >
> > I'm looking to stream documents to the Daeja ViewOne Viewer applet
using
> a
> > single URL.  I understand that a document can be retrieved from the
> > repository using a URL like so:
> >
> >
> http://host:port
>
> >
> >
> /fncmis/resources/DEV/ContentStream/idd_9B7C7D0A-A236-489C-A512-AB32B2E676D7/0/document1.xlsx

> >
> > However the server prompts the user for basic HTTP authentication
> > credentials.  It looks like Alfresco has a way to deal with this:
> >
> > https://wiki.alfresco.com/wiki/URL_Addressability
> >
> > Is there anything similar we can do for FileNet?
> >
> > Sorry a bit off-topic, but if there are any IBM people out there, do
you
> > know if credentials can be supplied to the Daeja ViewOne applet? Maybe
> this
> > would be a way to deal with it instead...
> >
> > Thanks,
> >
> >
> >
>
>
>

Reply via email to