Content Management and Capture

Content Management and Capture

Come for answers. Stay for best practices. All we’re missing is you.

 View Only
Expand all | Collapse all

FileNet Token based authentication

  • 1.  FileNet Token based authentication

    Posted Tue April 29, 2025 04:58 PM

    I am trying to get the P8 connections with OKTA token but it is saying user not authenticated with the sample code given in the below tech note link. Can any one suggest me with the required steps to generate the required OKTA token with any specific claims and authenticate it P8.
    Security - Single sign-on integrations via Content Engine API Bearer Token Authentication

    Ibm remove preview
    Security - Single sign-on integrations via Content Engine API Bearer Token Authentication
    The Bearer Token Authentication support added to the Content Engine API allows any client, regardless of whether it runs in an application server, standalone java application, or servlet, to pass a user's identity for Single sign-on to the Content Platform Engine server.
    View this on Ibm >

     



    ------------------------------
    Ravi Kiran Saladi
    ------------------------------


  • 2.  RE: FileNet Token based authentication

    Posted Wed April 30, 2025 09:41 AM

    Hi Ravi

    Have you read this article and links within?

    https://community.ibm.com/community/user/blogs/roger-bacalzo1/2020/12/17/how-to-configure-sso-between-icn-and-cpe

    Regards, Kenny



    ------------------------------
    Kenny Dick
    ------------------------------



  • 3.  RE: FileNet Token based authentication

    Posted Mon May 05, 2025 09:27 AM

    Hi Kenny Dick,

    Thanks for your response!

    Yes, we did follow the Roger's tech note and with the help of Roger, we successfully implemented OKTA Token authentication in our custom Spring boot REST API with OIDC RP client and interceptors in WebSphere server, which authenticate and authorize every user request and allow the user to download/ add documents with custom REST API.

    Now we wanted to make use of CPE 5.5.9 token based authentication feature in our custom REST API. Our understanding is, this new OpenTokenCredentials class will directly authenticate the user token without OIDC RP client, so that we can eliminate the RP client and interceptors dependency.

    Please correct me if my understand is wrong and suggest me the steps to make use of OpenTokenCredentials to authenticate the user okta token and allow the user to view/add the documents and please let me know the required token type(web app, API app) and claims.

    Thank you!



    ------------------------------
    Ravi Kiran Saladi
    ------------------------------



  • 4.  RE: FileNet Token based authentication

    Posted Mon May 05, 2025 10:43 AM

    Hi Ravi

    Following with interest here as I believe from working with Roger & IBM Support earlier this year that the new capabilities in V5.5.9+ (OpenTokenCredentials) requires the OIDC setup you mention. We certainly required that to use it which is working nicely.

    I'll be following this thread now to see what if anything has changed in my understanding of the info shared by Roger and Co earlier.

    Regards, Kenny

    @ROGER Bacalzo



    ------------------------------
    Kenny Dick
    ------------------------------



  • 5.  RE: FileNet Token based authentication

    Posted Mon May 05, 2025 01:02 PM

    The Bearer token authentication mechanism introduced in 5.5.9 and described in https://www.ibm.com/docs/en/filenet-p8-platform/5.6.0?topic=authentication-single-sign-integrations-via-content-engine-api-bearer-token, is meant to be used by CPE client applications to send an OAuth/OIDC Bearer token on CPE API requests for authentication.  It requires the client application to obtain this OAuth/OIDC token.

    If the CPE client application runs on WebSphere, then this mechanism isn't required, since the CE API can directly obtain the OAuth/OIDC token from the currently logged in user, provided that user authenticated with an Identity Provider that supports OAuth/OIDC. 

    This mechanism is primarily useful for those CPE client applications that do not run on WebSphere.  So if you don't want to run your application on WebSphere, then this mechanism gives you the flexibility to run it on any framework you like that supports Java or .NET and use the CPE API to send the OAuth/OIDC token that you've obtained to the CPE server for authentication.  Again, it's your applications responsibility to obtain this OAuth/OIDC token, since you won't be using WebSphere to do it for you.



    ------------------------------
    ROGER Bacalzo
    ------------------------------



  • 6.  RE: FileNet Token based authentication

    Posted Tue May 06, 2025 12:58 PM

    Hi Roger,

    Thanks for your detailed explanation.

    Hope you remember, you helped us to integrate Spring REST API (for FileNet functionalities like document upload and retrieve) with OKTA app (PKCE) using WebSphere OIDC RP client and interceptors. OIDC RP client validate the client token and convert that into LTPA token and with that we are receiving user context in our REST API and creating CPE connection to perform P8 operations. Here RP client and REST API are in WebSphere 9 and CPE is in WebSphere 8.5.5. And REST API is working as expected with the provided token in request header.

    Below is our new use case with CPE 5.5.9 OpenTokenCredentials:

    Can we use the 5.5.9 OpenTokenCredentials class to authenticate the user token and get CPE connection to perform the P8 operations directly in REST API without OIDC RP client ? If so, what are the prerequisites to implement it. 
    FYI.. We just give a try with the given OpenTokenCredentials sample code to get the P8 connection with OKTA access token  but we are getting user not authenticated exception.

    Please suggest!



    ------------------------------
    Ravi Kiran Saladi
    ------------------------------



  • 7.  RE: FileNet Token based authentication

    Posted Tue May 06, 2025 04:56 PM

    The OpenTokenCredentials class cannot authenticate a user token.  It is used to take an already authenticated token and pass that on CPE API requests to the CPE server.

    You application must authenticate the user token.  If your application is running in WebSphere, that is what the OIDC RP client does for you.

    If you want to run your Spring REST API in a different application server or web server, then you must use the mechanisms available on those servers to perform the authentication.

    Once the request is authenticated at your Spring REST API, then you can obtain the authenticated token in your application and invoke the CPE API request using the OpenTokenCredentials class. 



    ------------------------------
    ROGER Bacalzo
    ------------------------------



  • 8.  RE: FileNet Token based authentication

    Posted Tue May 06, 2025 07:57 PM

    Also, if you are passing the OAuth/OIDC token received from Okta to the CPE Server using the OpenTokenCredentials, make sure the CPE server has also been configured to authenticate these tokens with a WebSphere OIDC RP configuration. 

    If you were previously passing an LTPA token to the CPE server, then you did not need the CPE OIDC RP configuration.  Now that you are passing an OAuth/OIDC token to the CPE server, you need CPE's WebShere instance to process this token via an OIDC RP configuration.



    ------------------------------
    ROGER Bacalzo
    ------------------------------



  • 9.  RE: FileNet Token based authentication

    Posted Fri May 09, 2025 04:45 PM

    Hi everyone,
    My tests with Liberty feature mpJwt-2.1 and ADFS JWT (and Spring Boot 3, but that doesn't really matter) work without the class. As far as I understand, authentication to CPE continues with LTPA.
    @Ravi Maybe you could consider migrating to Liberty.



    ------------------------------
    Andrey Voronin
    ------------------------------



  • 10.  RE: FileNet Token based authentication

    Posted Thu June 19, 2025 03:45 PM

    Hi Roger,

    As per your suggestion, we tried with OIDC RP client with test app which has OpenTokenCredential token based authentication and it looks good.
    Thanks for your inputs to make it works.

    We have other challenge I wanted to check with you, Hope you remember we did setup OIDC interceptors for our REST API to authenticate the user token and it is working as expected.

    Now we wanted to add one more provider for the same REST API with same filter and with different issuerIdentifier, jwkEndpointUrl, userIdentifier.

    But when we pass the token which is generate with new okta issuer and we are not getting caller subject in our REST API and as per the trace log it is referring other provider jwkEndpointUrl to validate the token.

    Could you please suggest us if there is any way to differentiate the call to validate the token even if we use same filter with different issuerIdentifier, jwkEndpointUrl, userIdentifier?

    Thank you so much for all your assistance! 



    ------------------------------
    Ravi Kiran Saladi
    ------------------------------



  • 11.  RE: FileNet Token based authentication

    Posted Fri June 27, 2025 01:42 PM

    Hi Ravi,

    If you want to use a different provider in your WebSphere OIDC configuration, you must have a filter that can differentiate which provider to use.  

    Look at the filter options described in https://www.ibm.com/docs/en/was/9.0.5?topic=swss-saml-web-single-sign-sso-trust-association-interceptor-tai-custom-properties#rwbs_samltaiproperties__samltaifilterprop

    WebSphere's OIDC configuration uses the same filter mechanism as it's SAML configuration.  

    If there's something in the HTTP Request header or in the URL that can differentiate which provider to use, that's the best option.  Otherwise, you might have to define a new context root for your REST API, such that you have a different context root for each provider you wish to authenticate against or add a different URL parameter to let your filter distinguish among your providers.

    The filter can't look at the body of your HTTP request.  So you're limited to what the WebSphere filtering mechanism defined in their documentation allows.



    ------------------------------
    ROGER Bacalzo
    ------------------------------



  • 12.  RE: FileNet Token based authentication

    Posted 6 days ago
    Edited by Ravi Kiran Saladi 6 days ago

    Hi Roger,

    We did implement the FileNet connection using OpenTokenCredentials in our REST API and we are able to perform the p8 operations. But we have one challenge while implementing it.

    As part our REST API, we placed all p8 connection in one service class and we used to call connection method in other service classes to performing p8 operations, but when we use OpenTokenCredentials approach which can return ObjectStore object and use the same objectstore object out side of the class then we are facing security issues saying user is not authorized do perform particular p8 operation. Where as, If I implement everything under OpenTokenCredentails >> PrivilegedExceptionAction >> run() which contains p8 connection and fetch document.

    I just want to understand, Can we fetch the objectStore object as per below link and return to parent class and perform required p8 operations ? 

    https://www.ibm.com/docs/en/filenet-p8-platform/5.5.x?topic=authentication-v559-later-single-sign-integrations-via-content-engine-api-bearer-token

    Or all operations like, fetch domain, fetch objectstore and fetch document everything under run() ?

    Below is our code where we are doing complete end-end operation at one place and which is working fine but I believe it is not suggest approach.

    public DocOperationsModel getDocumentStreamwithOpenTokenCredentials(String clientUser,String oauthToken, String xAuthFlow,
    String MTOM_URL, String domainName, String osName, String docId) {
    // Create instance of class used to pass OAuth token to WSI requests using CE API
    String methodName = "getDocumentStreamwithOpenTokenCredentials";
    LOGGER.debug("Connecting to FileNet with OpenTokenCredentials");
    OpenTokenCredentials otc = new OpenTokenCredentials(clientUser, oauthToken, xAuthFlow);//we are using realm parameter to pass xAuthflow to filter the request in OIDC RP client.
    LOGGER.debug("User Name : "+otc.getUsername());
    LOGGER.debug("token :" +otc.getToken());
    ObjectStore objectStore=null;

    PrivilegedExceptionAction<DocOperationsModel> getdocumentStream = new PrivilegedExceptionAction<DocOperationsModel>() {
    public DocOperationsModel run() {
    Connection conn=null;
    Domain domain=null;
    ObjectStore os=null;
    InputStream documentStream=null;
    PropertyFilter filter=new PropertyFilter();
    DocOperationsModel dcModel=new DocOperationsModel();
    try {
    //System.out.println("Before Connection: "+MTOM_URL);
    LOGGER.debug("MTOM_URL from config : "+MTOM_URL);
    LOGGER.debug("Domain Name from config : "+domainName);
    conn=Factory.Connection.getConnection(MTOM_URL);
    LOGGER.debug("Connection established : "+conn);
    domain = Factory.Domain.fetchInstance(conn, domainName, null);
    LOGGER.debug("Got domain: " + domain.get_Name());
    os = Factory.ObjectStore.fetchInstance(domain, osName, null);
    LOGGER.debug("ObjectStore Name : " + os.get_DisplayName());
    Document doc = Factory.Document.fetchInstance(os, docId, filter);
    LOGGER.debug(methodName+ " Document fetched with Id : " + docId);
    ContentElementList docContentList = doc.get_ContentElements();
    if (!docContentList.isEmpty()) {
    Iterator<?> iterate = docContentList.iterator();
    if (iterate.hasNext()) {
    ContentTransfer ct = (ContentTransfer) iterate.next();
    LOGGER.info(methodName + ", Document content size : " + ct.get_ContentSize());
    LOGGER.info(methodName + ", Document content retrieval name : " + ct.get_RetrievalName());
    documentStream = ct.accessContentStream();
    dcModel.setDocInputStream(documentStream);
    LOGGER.debug("Document stream retrieved successfully" + ct.get_RetrievalName());
    dcModel.setDocRetrievalName(ct.get_RetrievalName());
    dcModel.setDocMimeType(ct.get_ContentType());
    }
    }
    } catch (Exception e) {
    //e.printStackTrace();
    LOGGER.error("Error in getDocumentStreamwithOpenTokenCredentials: " + e.getMessage());
    }
    return dcModel;
    }
    };
    DocOperationsModel docOpModelFinal = otc.doAs(getdocumentStream);
    return docOpModelFinal;
    }

    With this method finally we recieving document stream and its mime type and docoument title through a bean object in controller class.

    If I return only ObjectStore object to the parent class to perform the p8 operations in different service class the we are getting this error:

    Unable to  download document - Access to the Content Engine was not allowed because the Content Engine API library or the Web Service Interface (WSI) Listener could not find the required security context information. Expected credentials were not found in the security context.

     

    We want to unpack it and implement it in different class methods.

    Please suggest us with best implementation steps

    Thank you!



    ------------------------------
    Ravi Kiran Saladi
    ------------------------------



  • 13.  RE: FileNet Token based authentication

    Posted 6 days ago

    You should pass back the OpenTokenCredential instance (e.g. otc) in addition to the ObjectStore in your service class, so that it can be reused in your other service classes.  All FileNet operations should be done within a otc.doAs() method in a PrivilegedExceptionAction in your other service classes.  The ObjectStore that you pass back should also be defined as final so that it can be used directly in these other PrivilegedExceptionAction methods in your other service classes.



    ------------------------------
    ROGER Bacalzo
    ------------------------------



  • 14.  RE: FileNet Token based authentication

    Posted 5 days ago

    Thanks for the clarification Roger!

    As per your input, I hope I am doing the same with above code snippet where I am performing FileNet operations along with fetch objectstore in PrivilegedExceptionAction within otc.doAs(). If that is correct every p8 operations service class should have below steps to fulfill the p8 operation(Ex: download document) which includes create connection, fetch domain, fetch objectstore and followed by p8 operations and we can not keep fetch objectstore code in separate common service class bcoz it is losing the user context if we pass back to other service class where we are doing actual p8 operation and I did try to pass back final objectstore object to other service class but I am facing "Expected credentials were not found in the security context" while executing p8 operation.

    Hence my understanding is, we can not implement them in 2 different service class where one service class is with fetch objectstore and return the objectstore instance and other service class is to collect the objectstore object and perform p8 operations.

     Please correct me If I am wrong. 

    Below is the code snippet which is working fine, If I try to breakdown them into 2 different service classes by sharing objectstore instance and which is causing issue : "

    Unable to  download document - Access to the Content Engine was not allowed because the Content Engine API library or the Web Service Interface (WSI) Listener could not find the required security context information. Expected credentials were not found in the security context."
    OpenTokenCredentials otc = new OpenTokenCredentials(clientUser, oauthToken, realm);
    PrivilegedExceptionAction<DocOperationsModel> getdocumentStream = new PrivilegedExceptionAction<DocOperationsModel>() {
    public DocOperationsModel run() { .....P8 operation along with create connection, fetch domain, fect objectstore then followed by p8 operation
    return <p8 operation results bean>;
    };
    DocOperationsModel docOpModelFinal = otc.doAs(getdocumentStream);



    ------------------------------
    Ravi Kiran Saladi
    ------------------------------



  • 15.  RE: FileNet Token based authentication

    Posted 3 days ago

    Ravi,

    While you do have to execute all FileNet operations w/in a PrivilegedExceptionAction, you should not need to perform all the create connection, fetch domain, fetch objectstore operations in each one.  The ObjectStore you get once when you obtain it using an otc.doAs method should be usable in other PrivilegedExceptionAction's that you use with otc.  You might have to pass in the ObjectStore as a parameter to these other PrivilegedExceptionAction's or as a final variable.



    ------------------------------
    ROGER Bacalzo
    ------------------------------