IBM Security Verify

 View Only
Expand all | Collapse all

Enterprise back-end services modernization and OAuth

  • 1.  Enterprise back-end services modernization and OAuth

    IBM Champion
    Posted Sat November 28, 2020 01:25 PM

    Use Case : Enterprise back-end services modernization

    Driver: Underlying application server technology shift

    The application server technology foundation for some internal facing Enterprise Web Services is undergoing a technology shift from J2EE runtimes to lighter container-like runtimes. It means the traditional J2EE/ORB communication layer that used to somehow secure the communication channel between Web service clients and services is now simply "gone". Recognizing the need to maintain/augment the security posture, it was agreed to use OAuth Client Credentials grant type for the authentication/authorization portion between Web Service clients and Web Services. The Enterprise Web Services however are not landing necessarily in an industry award winning API Gateway. Instead, the modernization will incrementally address the end-to-end flow, not all component at once.

    Although ISAM can play the OAuth Authorization Role by exposing internally the /token endpoint to Web Service clients, the OAuth Resource Server role will be assumed by the Web Services "application" layer, with no format API gateway component.

    The plan is thus for the Web Services application layer to use /introspect endpoint calls to OAuth Authorization Server (ISAM) to validate OAuth access tokens received in the stream of incoming Web Service calls. Different OAuth scopes will serve to identity the permission(s) required on each Web Services, and each Web Service clients is to be delivered a unique pair of Client ID/Secret thus allowing for end-to-end traceability, and some finer-grain access control and monitoring (consumption insights).

    What came as a surprise however to the development team is when they were told their application layer needed assume all functions of an OAuth Resource Server when consuming claims contained in the JSON response from the /introspect call. As a reminder, here is an example of a generic JSON response from the /introspect endpoint.

    { "scope": "read write",   "active": true,   "token_type": "bearer",   "exp": 1496334738333,   "iat": 1496331138333,   "client_id": "testclient",   "username": "emily"}

    Hence, the application layer needs not just inspect the "active" claim but also to check that the "client_id" returned is indeed authorized on the described scope(s). The reason for this I explained is you don't want a legitimate OAuth client (only authorized on scope "read") to attempt obtaining a "write" scope from the /token endpoint (by default there is no logic filtering  scope(s) requested during the /token endpoint call), and then later make calls at Web Services that only accept "write" permissions.

    In our original session, we ended up drawing a list of candidate solutions/alternatives:

    1. Web Services application layer to fully assume the OAuth Resource Server role, meaning maintaining a list of scopes and their authorized client_ids for performing itself the authorization decision. This can lead to dispersed authorization functions and its parts and also to high maintenance. The Dev team wasn't sure they liked this new responsability throwed at their end (remember, they used to get security for "free" before with J2EE/ORB).
    2. Web Services application layer assuming only partially the OAuth Resource Server role by delegating to the /introspect endpoint logic (on OAuth Authorization Server side) the authorization decision, based on a maintained list of scopes and their authorized client_id inside mapping rules customization.
    3. Web Services application layer assuming only partially the OAuth Resource Server role by delegating to the /token endpoint logic (on OAuth Authorization Server side) the authorization decision based on a maintained list of scopes and their authorized client_id (mapping rules customization). In this case, the authorization decision is performed when the access token is requested so it would happen only once. But no ... we still end-up having to replicate that authorization logic also during the /introspect endpoint call, which leads to a waste of processing time.

    In all cases, I encourage the Web Services application layer team to maintain a timed-base cache of already authorized OAuth token in order to reduce the toll on the OAuth Authorization Server infrastructure resources.

    Am I heading the dev team in the right direction by suggesting that our best option is option B) ? The reason that I am favoring option B) over A) is to regroup every token operations (issuance and authorization) in a single location (less moving part all over the place), and also make things simpler for the dev team.

     Thanks in advance for your comments



    ------------------------------
    Sylvain Gilbert
    ------------------------------


  • 2.  RE: Enterprise back-end services modernization and OAuth

    Posted Mon November 30, 2020 01:31 AM

    Personally I think policy such as that you've outlined should be implemented at both the /token and /introspect endpoints. A client should not be able to successfully "request" scope that it is not entitled to, and nor of course should it be able to perform actions at runtime that it's not entitled to.

    As for the logic of implementing the call to the introspect endpoint, and caching (for the life of an access token) the authorization result, have you considered the IBM Application Gateway (http://ibm.biz/ibm-app-gateway) as a lightweight container-based proxy that your web services application layer team might run in front of their application layer implementation of web services to cover those roles (validating access tokens and caching results)?



    ------------------------------
    Shane Weeden
    IBM
    ------------------------------