Layer7 API Management

 View Only
  • 1.  OTK Database usage in Portal and Gateway

    Posted Nov 13, 2019 10:51 AM
    Hi!

    Have a question related to how the OTK databases are maintained between Portal and Gateway.
    1. When it comes to Gateway, during token validation does the Gateway hit the OTK_DB every time to look up the token or caches it in some form ?
    2. When an app is created at the Portal, does it get persisted within the portal database ? How does it get synced with the Gateway so that gateway is aware of these credentials ?


    Thanks!


  • 2.  RE: OTK Database usage in Portal and Gateway

    Broadcom Employee
    Posted Nov 19, 2019 09:44 AM
    Hi Mohammad,

    Tokens are typically cached. Can you confirm the version of the developer portal you are using?

    Regards,
    Joe


  • 3.  RE: OTK Database usage in Portal and Gateway

    Posted Nov 19, 2019 09:27 PM
    Hi Joe!

    Thanks for your response.
    we use API Portal 4.3.2



    thanks,
    imran


  • 4.  RE: OTK Database usage in Portal and Gateway
    Best Answer

    Broadcom Employee
    Posted Nov 20, 2019 01:37 AM
    Hi,
    1. Depends on how Require OAuth2.0 Token is configured. ( Cache Validation Result field ). If its 0 it will goto DB each time, otherwise it will use cached result for that specified time in msecs. 

    2. Yes its persisted. It is stored inside portaldb containers psql "portal" database ( inside container psql portal admin  , password 7layer ). Gateway syncs apps, apis etc periodically using Scheduled Task mechanism. It stores these information inside otk database tables.


  • 5.  RE: OTK Database usage in Portal and Gateway

    Posted Nov 29, 2019 03:13 AM
    Thanks for details Ozan Okan! It is helpful.

    Cheers
    Imran


  • 6.  RE: OTK Database usage in Portal and Gateway

    Posted Nov 28, 2019 02:48 PM
    Hi,

    I'll try to add more information based on my experience in Portal 4.3.2

    1. When it comes to Gateway, during token validation does the Gateway hit the OTK_DB every time to look up the token or caches it in some form ?

       - Gateway use It's own OTK_DB to validade requests using tokens from Apps created using Portal..
       - In OTK_DB an App is nothing more than a new OAuth Client entry in OTK Database.
       - Token Validation occurs the same way as "regular" Gateway OAuth Tokens (as expained in an earlier response to this post).
       - When you publish an API using portal and select the "Standard Policy Template - OAuth 2.0" to authorize the requests, there is no caching (value is set to zero). I haven't tested it, but in this case I believe It will hit the OTK_DB every time to look up the token.


       As a product enhancement, It would be nice if there was a parameter to set the cache validation time when deploying the API using this template, together with the "SSL", "SLA", "Debug Mode" and other Custom Parameters. The default behavior, if confirmed, will add extra overhead and resources consumption to the Gateway. In the meantime, the value can be adjusted manually, best if first cloning the default template and creating a new policy template with the changes.



    2. When an app is created at the Portal, does it get persisted within the portal database ? How does it get synced with the Gateway so that gateway is aware of these credentials ?

       - When you Enroll a Gateway with portal, several Scheduled Tasks are added to the Gateway. These scheduled tasks runs periodically syncing the information between Gateway and Portal (as expained in an earlier response to this post)..


    The result of the scheduled task's execution is what you see in Portal's Proxy Details page (the "Proxy" side), together with Portal's own database info (the "Portal" side).


      Communication between Portal and Gateway always flows in Gateway -> Portal direction. 

      Regards,

    Marlos Chida


  • 7.  RE: OTK Database usage in Portal and Gateway

    Posted Nov 29, 2019 03:15 AM
    Hi Marlos Chida!

    Thanks for providing a very detailed inputs for my queries.
    helpful !


    Thanks,
    Imran