Archive

Expand all | Collapse all

Multiple Calls/Requests into a Single API

Jump to Best Answer
  • 1.  Multiple Calls/Requests into a Single API

    Posted 10-31-2018 12:03 PM

    Hi everyone,

     

    I am in need of some assistance or guidance. I am trying to integrate with CA Single Sign-On (Siteminder) in terms of just making REST API calls to the SSO API endpoints. I am trying to work within the API Gateway to do all of this and make testing/template policies for future use cases.

     

    I want to build out a policy that allows me to make multiple calls/requests in a single API. How would that be done??

     

    If I am trying to hit a testing SSO endpoint - it requires me to have a JWT or Bearer Token. I can hit the endpoint URL directly or even if I set a Routing assertion with that endpoint inside my Gateway/policy. I do most of my testing on Postman. The result should show me all the say if I set the URI to list all the SmDomains on our testing Policy Server. 

     

    I just was asking in terms of does anyone know of a "basic and easy" way to where I make a REST call and receive the sessionkey/token and use that token to make another call to that same endpoint URL but with different URI/parameter??

     

    What I have so far in my testing policy is:

    - Audit Message in Policy

    - At least one ...

       - All must be ...

       - Require HTTP Basic Credentials

       - Route via HTTPS ... (to the REST API to pull a token)

     

    (^^ this works in giving me a token - 

    1.  Here if I go to Postman with the URL: POST https://<gateway:port>/ca/api/sso/services/login/v1/token (withe SSO login credentials) from -- Administrative Token API - CA Single Sign-On - 12.8 - CA Technologies Documentation   

    2. I should get in the Response section get a session key.

    3. For instance, from the list of SSO REST APIs -- Policy Data API - Core Policy Objects - CA Single Sign-On - 12.8 - CA Technologies Documentation  -- if I copied that same key/token I just generated and made another request:

    GET https:<gateway:port>/ca/api/sso/services/policy/v1/SmDomains
    I set the Authorization header as Bearer Token and pasted the token -- ran the request and it displays the information I need; I am just trying to replicate this process in my Gateway as a single request instead of separate, individual requests, etc.)

     

    I have tried followed the instructions from this link I'm trying to request a token in the first call and pass it to second call. but I do not know how to setup the "Evaluate JSON Path Expression Assertion with the response from the first call as input" in step 1. I have also tried step B in changing the header value within the Routing properties but I am not sure if that should be done on the first Routing assertion or make another Routing assertion with those configurations?

     

    If anyone can assist me on this process, it would be greatly appreciated!

     

    Thanks,

    Tiffany K



  • 2.  Re: Multiple Calls/Requests into a Single API
    Best Answer

    Posted 10-31-2018 02:52 PM

    Hi Tiffany,

     

    As I understand, you need to hit one URL to get the token, then use this token to hit another endpoint, is that right?

    By " replicate this process in my Gateway as a single request" do you mean as part of the same policy?

     

    I don't know the format of token you are receiving back, but we will assume JSON here as you mentioned bearer or JWT.

     

    Example Response from the first endpoint:

    {   "access_token":"ea05bbcf-ab6c-4eac-a7a6-0ca0d19fcff3",   "expires_in":3600,   "scope":"sso" }

    The policy would look something like this.

     

    Breakdown:

    Line 2: We want all assertions to succeed

    Line 3: Route to the endpoint that gets the Token

    Here in the HTTP route properties we can capture the response in the Response Destination field. Simply enter a name and the variable will be created if it does not exists. So if this endpoint returns the JSON in my example above it will be put into the variable tokenResponse

     

     

    Line 4: We use an Evaluate JSON Path Expression to get just what we need from the JSON.

    JSON path expressions allow you to parse throw JSON for specific values (ref: JSONPath - XPath for JSON )

     

    For my example we just want the value in "access_token", so a simple expression is .access_token 

     

     

     

    To make sure this acts against the variable (tokenResponse) we got from the route assertion, simply right click on the Evaluate JSON path and click on 'Select Target message', you can now set this to the variable

     

     

    Line 5: Route to the destination that requires the token

    Here we can include the header with the new variable we got from the JSON path exression

     

     

    Hope this helps. 

    Please let me know of any questions.

     

    Regards,

    Joe



  • 3.  Re: Multiple Calls/Requests into a Single API

    Posted 10-31-2018 05:05 PM

    I should note in the case of the JWT this assumes it   was decoded first to get the actual JSON payload.



  • 4.  Re: Multiple Calls/Requests into a Single API

    Posted 11-01-2018 10:55 AM

    So in terms of that note, what should I do or do I need to make any other changes? I got the token successfully but when I try to route to the other URL - it gives me a Assertion Falsified.



  • 5.  Re: Multiple Calls/Requests into a Single API

    Posted 11-02-2018 08:28 AM

    Hi Tiffany,

     

    I would need a bit more details about the error. Do you see anything additional in the log?

    Or perhaps you can add the assertion 'Customize SOAP Fault Response' assertion to the top of your policy and set it to 'Full Detail'

     



  • 6.  Re: Multiple Calls/Requests into a Single API

    Posted 11-02-2018 09:52 AM

    Hey Joe,

    I have inserted the Custom SOAP Fault Response assertion as you mentioned previously to my policy.

    Policy in my Gateway

    (Note: The first Routing assertion is a Single Sign-On REST API to request for an Administrative Token with the POST verb; that I also set in the HTTP Properties as the HTTP Method - Administrative Token API - CA Single Sign-On - 12.8 - CA Technologies Documentation)

    The second Routing assertion as I said previously before, is the endpoint where I am trying to pull a list of all the Domains listed on the SSO Policy Server from the Core Policy APIs - Policy Data API - Core Policy Objects - CA Single Sign-On - 12.8 - CA Technologies Documentation)

     

    I have successfully followed your instructions from your post above of step-by-step on what to do. Does this look correct?

     

    However, when I run a request on Postman of my custom resolution path with that policy - this is the response that I receive:

    Response from Policy in Postman

     

    I do not know if this is an issue pertaining to my Gateway in terms of Authentication/Authorization or if it is on the Siteminder/SSO server side. I don't know if it's not utilizing the token? Or if I need to provide the user/pass credentials again somehow? Etc.

     

    Again, on Postman as long as I have the routing endpoint, encoded the user and password into a string as my Basic authentication and ran the request with the administrative token API; I would receive that session key. I'd copy and paste the session key as a Bearer Token authorization method on Postman with a Core Policy API endpoint and I would receive the information needed.

     

    Please let me know what you think based off the information I've provided.

     

    Thanks so much,

     

    Tiffany K



  • 7.  Re: Multiple Calls/Requests into a Single API

    Posted 11-02-2018 02:06 PM

    From the SOAP response error shown, it implies that your routing assertion was marked as falsified because the backend (downstream service) returned an HTTP 401 status code.

     

    A 401 status code means "Unauthorized". This will generally be seen when credentials were seen (which your SOAP response shows it found the user of "siteminder") but they were deemed invalid.

     

    Examples of this include using a cookie which has since expired, a typo in a username or password, credentials correct but for a user account that has been marked disabled, etc.