Hi Megala, On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[email protected]> wrote:
> Hi All, > > I am currently working on $subject for APIM 2.x. Currently all the APIs > are protected with oauth2 token, with this feature, the API > creators/publishers will be given the flexibility to select different > options to secure their APIs (i.e. Options can be oauth2, mutal ssl or > both). Userstory for this feature can be found at [1] > > *Option 1 - oauth2* > This will follow the same old flow when invoking the API. > > *Option 2 - Mutual SSL* > If this option is selected, the authentication will be handled in the > transport level and in the handler level, we do not need to do the > authentication explicitily. > > *Option 3 - oauth2 and mutal SSL* > The authentication will be handled in transport level as well as in > handler level. > > In the above options, option 2 has some unclear areas that need to be > sorted out. > > *How to handle the scope validation* > Authentication will be handled with the client certificates, however for > scope handling we need role/scope information(i.e. authorization > information). As per specification[2], it seems attribute certificate is > used for this purpose, which incudes the authorization information. However > it seems it seems there seems to be no proper support for such certificate > as of [3]. In that case, we may need to get the scope information from the > public certificate, may be we could use certificate extension for that > purpose, however seems we do not have a standard extension for the relevant > purpose. > AFAIK there is no standard certificate extension to save scope values, If we use wso2 proprietary certificate extension attribute , then users with valid CA signed x509 certificate won't be able to access the APIs. Or if use proprietary attribute for scopes users will have to generate certificates with those extension attributes. > > *How to support client certificates upload* > When we support mutual SSL, we may need to provide the way to upload the > client certificates. For this we can make use of the same way we have used > for dynamic ssl certification handling for backend. Similar to sender, > dynamic ssl certification is supported for listeners as well. Hence we > could use the similar implementation to support this usecase. > > *Application subscription and related functionalities and a**nalytics > related functionalities* > We retrieve the subscription information from the authenticated token. > Since we do not have any token's involved, subscription and related > functionalities will not work. > Analytics related functionalities need to be verified as well in the same > flow. > In mutual ssl flow we will have to skip the subscription validation, since there is no valid subscription. Subscription related analytics and throttling should also be skipped. > > *Modification Store API Console* > With this feature, we may need to consider the modifications that need to > be done to swagger API console in store to support calling APIs with mutual > SSL. > > Currently I am working on POC setup for this feature to figure out > possible solutions for these uncler areas. Appreciate your suggestions on > this. > > [1] > https://docs.google.com/document/d/1syUw22Re9wLbomyYfQAP-EI-UWl9FnBrCGLHJ0L54Kg/edit?usp=sharing > [1] https://tools.ietf.org/html/rfc5755 > [2] > https://security.stackexchange.com/questions/101351/attribute-certificates-and-access-management > > Thanks. > > Regards, > Megala > -- > Megala Uthayakumar > > Senior Software Engineer > Mobile : 0779967122 > -- Rajith Roshan Senior Software Engineer, WSO2 Inc. Mobile: +94-7 <%2B94-71-554-8430>17-064-214
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
