Re: [Architecture] [AM] Securing APIs using Mutal SSL
Hi All,
Currently I am looking into adding Rest API to achieve the same
functionality. For the Rest API support of dynamic SSL based certificate,
we have provided following Rest API resources to support the functionality,
*public abstract Response certificatesAliasContentGet(String alias);public
abstract Response certificatesAliasDelete(String alias);public abstract
Response certificatesAliasGet(String alias);public abstract Response
certificatesAliasPut(InputStream certificateInputStream,Attachment
certificateDetail,String alias);public abstract Response
certificatesGet(Integer limit,Integer offset,String alias,String
endpoint);public abstract Response certificatesPost(InputStream
certificateInputStream,Attachment certificateDetail,String alias,String
endpoint);*
I think we can also, go with the same set of similar resources for the
client certificate managerment, instead of endpoint, apiId will be used for
the client certificate management usecase. Appreciate your thoughts on this.
Thanks.
Regards,
Megala
On Fri, Sep 21, 2018 at 5:16 PM Megala Uthayakumar wrote:
> Hi Ishara,
>
> On Fri, Sep 21, 2018 at 4:52 PM Ishara Cooray wrote:
>
>> Hi Megala,
>>
>> "REMOVED" and "UNIQUE_IDENTIFIER" fields have been newly introduced for
>> the following purposes.
>> When we delete the uploaded certificate from UI, that change will not be
>> immediately reflected in the gateway environment, until the user clicks on
>> "Save and Publish" button. In that case, when the delete button is clicked
>> for the certificate, relevant entry related with certiifcate in the
>> database will not be deleted, rather that entry will be updated with the
>> value "REMOVED" to true. Then the entry will be removed from the databse,
>> once the changes are published to the gateway.
>> Further "UNIQUE_IDENTIFIER" field was introduced, as when a API is
>> authenticated against a certificate using mutual SSL, the axis context will
>> only hold the certificate as a property, it will not contain the alias of
>> the certificate. Hence when a mutual ssl authenticated request received in
>> the gateway, "UNIQUE_IDENTIFIER" (i.e. combination of certificate serial
>> number and issuer dn) will be used to check the subscription tier of
>> particular certificate by making a call to key manager. Hence the
>> throttling key will be {{UNIQUE_IDENTIFIER of certificate}}__{{API
>> Identifier}}.
>>
>> +1
>> I prefer field UNIQUE_ID than UNIQUE_IDENTIFIER
>> wdyt?
>>
> +1 from me. Will use UNIQUE_ID.
>
> Thanks.
>
> Regards,
> Megala
> --
> *Megala Uthayakumar *| Senior Software Engineer | WSO2 Inc.
> (m) +94 779967122 | (e) meg...@wso2.com
>
>
--
*Megala Uthayakumar *| Senior Software Engineer | WSO2 Inc.
(m) +94 779967122 | (e) meg...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AM] Securing APIs using Mutal SSL
Hi Ishara,
On Fri, Sep 21, 2018 at 4:52 PM Ishara Cooray wrote:
> Hi Megala,
>
> "REMOVED" and "UNIQUE_IDENTIFIER" fields have been newly introduced for
> the following purposes.
> When we delete the uploaded certificate from UI, that change will not be
> immediately reflected in the gateway environment, until the user clicks on
> "Save and Publish" button. In that case, when the delete button is clicked
> for the certificate, relevant entry related with certiifcate in the
> database will not be deleted, rather that entry will be updated with the
> value "REMOVED" to true. Then the entry will be removed from the databse,
> once the changes are published to the gateway.
> Further "UNIQUE_IDENTIFIER" field was introduced, as when a API is
> authenticated against a certificate using mutual SSL, the axis context will
> only hold the certificate as a property, it will not contain the alias of
> the certificate. Hence when a mutual ssl authenticated request received in
> the gateway, "UNIQUE_IDENTIFIER" (i.e. combination of certificate serial
> number and issuer dn) will be used to check the subscription tier of
> particular certificate by making a call to key manager. Hence the
> throttling key will be {{UNIQUE_IDENTIFIER of certificate}}__{{API
> Identifier}}.
>
> +1
> I prefer field UNIQUE_ID than UNIQUE_IDENTIFIER
> wdyt?
>
+1 from me. Will use UNIQUE_ID.
Thanks.
Regards,
Megala
--
*Megala Uthayakumar *| Senior Software Engineer | WSO2 Inc.
(m) +94 779967122 | (e) meg...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AM] Securing APIs using Mutal SSL
Hi,
Please find the initial version design document for this feature in the
attachement.
Further following deviation is introduced to the initial design document,
Database schema is changed as follow,
CREATE TABLE IF NOT EXISTS `AM_API_CLIENT_CERTIFICATE` (
`TENANT_ID` INT(11) NOT NULL,
`ALIAS` VARCHAR(45) NOT NULL,
`API_ID` INTEGER NOT NULL,
`CERTIFICATE` BLOB NOT NULL,
`REMOVED` BOOLEAN NOT NULL DEFAULT 0,
`TIER_NAME` VARCHAR (512),
`UNIQUE_IDENTIFIER` VARCHAR (512),
FOREIGN KEY (API_ID) REFERENCES AM_API (API_ID) ON DELETE CASCADE ON UPDATE
CASCADE,
PRIMARY KEY (`ALIAS`, `REMOVED`)
);
"REMOVED" and "UNIQUE_IDENTIFIER" fields have been newly introduced for the
following purposes.
When we delete the uploaded certificate from UI, that change will not be
immediately reflected in the gateway environment, until the user clicks on
"Save and Publish" button. In that case, when the delete button is clicked
for the certificate, relevant entry related with certiifcate in the
database will not be deleted, rather that entry will be updated with the
value "REMOVED" to true. Then the entry will be removed from the databse,
once the changes are published to the gateway.
Further "UNIQUE_IDENTIFIER" field was introduced, as when a API is
authenticated against a certificate using mutual SSL, the axis context will
only hold the certificate as a property, it will not contain the alias of
the certificate. Hence when a mutual ssl authenticated request received in
the gateway, "UNIQUE_IDENTIFIER" (i.e. combination of certificate serial
number and issuer dn) will be used to check the subscription tier of
particular certificate by making a call to key manager. Hence the
throttling key will be {{UNIQUE_IDENTIFIER of certificate}}__{{API
Identifier}}.
Appreciate your thoughts on this change.
[1]
https://docs.google.com/document/d/1npruk2k_49hwPRcN06mF7BTFPr9ZfZ-km5YHdKze8Qo/edit
Thanks.
Regards,
Megala
On Thu, Sep 13, 2018 at 5:59 AM Ishara Cooray wrote:
> On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray wrote:
>
>> Hi Megala,
>>
>> In current authentication handler we set some API Parameters to
>> MessageContext such as
>> CONTEXT, API_VERSION, API, VERSION, RESOURCE, HTTP_METHOD, HOST_NAME,
>> API_PUBLISHER, etc.
>> We will need to do the same with the mutual ssl as well.
>>
>> To subscribe to an api currently we should have an oath application to be
>> used. So in this case even if we do not have any token involved I think
>> still we need let users to subscribe to the api.
>>
>> May be then we can store required subscription related information for a
>> given api.
>>
>> Even if we store the subscription details with the API, when a particular
> API is invoked how we know that this particular API invocation is related
> with this particular subscription, given that we do not have token involved
> with the request? AFAIU even if store it with the API, we will not be able
> to use them for subscription throttling. Please do correct me if I have
> misunderstood something regarding this
>
> Your understanding is correct indeed.
> However, for authorization we may be converting the client SSL
> certificate into an auth context.
> Please refer [1].
>
> 1. Client invoke an API by establishing a two way SSL session
>> 2. Gateway validates the client SSL certificate and translates it into an
>> auth context using the information from the subject distinguished name (DN).
>> 3. Gateway performs authorization by matching the auth context against
>> the target resource
>>
> wdyt?
>
> [1]
> https://blueprints.launchpad.net/keystone/+spec/client-ssl-certificate-authorization
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Wed, Sep 12, 2018 at 4:16 PM, Rajith Roshan wrote:
>
>>
>>
>> On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar
>> wrote:
>>
>>> Hi Rajith,
>>>
>>> Thanks for the response.
>>> On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan wrote:
>>>
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar
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
Re: [Architecture] [AM] Securing APIs using Mutal SSL
On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray wrote: > Hi Megala, > > In current authentication handler we set some API Parameters to > MessageContext such as > CONTEXT, API_VERSION, API, VERSION, RESOURCE, HTTP_METHOD, HOST_NAME, > API_PUBLISHER, etc. > We will need to do the same with the mutual ssl as well. > > To subscribe to an api currently we should have an oath application to be > used. So in this case even if we do not have any token involved I think still > we need let users to subscribe to the api. > > May be then we can store required subscription related information for a > given api. > > Even if we store the subscription details with the API, when a particular API is invoked how we know that this particular API invocation is related with this particular subscription, given that we do not have token involved with the request? AFAIU even if store it with the API, we will not be able to use them for subscription throttling. Please do correct me if I have misunderstood something regarding this Your understanding is correct indeed. However, for authorization we may be converting the client SSL certificate into an auth context. Please refer [1]. 1. Client invoke an API by establishing a two way SSL session > 2. Gateway validates the client SSL certificate and translates it into an > auth context using the information from the subject distinguished name (DN). > 3. Gateway performs authorization by matching the auth context against > the target resource > wdyt? [1] https://blueprints.launchpad.net/keystone/+spec/client-ssl-certificate- authorization Thanks & Regards, Ishara Cooray Senior Software Engineer Mobile : +9477 262 9512 WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware On Wed, Sep 12, 2018 at 4:16 PM, Rajith Roshan wrote: > > > On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar > wrote: > >> Hi Rajith, >> >> Thanks for the response. >> On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan wrote: >> >>> Hi Megala, >>> On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar >>> 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. >>> >> Agree on those points. I was thinking of giving the flexibility to API >> creator to decide on what is the certificate extension attribute, we need >> to get the scope from, may be we can have a optional attibute in API level. >> If the API creator does not want the APIs to checked against scopes, they >> can simply leave the field empty. WDYT? >> > > Seems fine. With this way api publishers can force the consumers to use > certificate with specific attribute to invoke the scope restricted apis. > Some what similar to psd2 APIs are protected using role check in EIDAS > certificate. > >> >> >>> *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
Re: [Architecture] [AM] Securing APIs using Mutal SSL
On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar wrote: > Hi Rajith, > > Thanks for the response. > On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan wrote: > >> Hi Megala, >> On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar >> 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. >> > Agree on those points. I was thinking of giving the flexibility to API > creator to decide on what is the certificate extension attribute, we need > to get the scope from, may be we can have a optional attibute in API level. > If the API creator does not want the APIs to checked against scopes, they > can simply leave the field empty. WDYT? > Seems fine. With this way api publishers can force the consumers to use certificate with specific attribute to invoke the scope restricted apis. Some what similar to psd2 APIs are protected using role check in EIDAS certificate. > > >> >>> *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 >> > > > -- > 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AM] Securing APIs using Mutal SSL
Hi Ishara, Thanks for the comments. On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray wrote: > Hi Megala, > > In current authentication handler we set some API Parameters to > MessageContext such as > CONTEXT, API_VERSION, API, VERSION, RESOURCE, HTTP_METHOD, HOST_NAME, > API_PUBLISHER, etc. > We will need to do the same with the mutual ssl as well. > > To subscribe to an api currently we should have an oath application to be > used. So in this case even if we do not have any token involved I think still > we need let users to subscribe to the api. > > May be then we can store required subscription related information for a > given api. > > Even if we store the subscription details with the API, when a particular API is invoked how we know that this particular API invocation is related with this particular subscription, given that we do not have token involved with the request? AFAIU even if store it with the API, we will not be able to use them for subscription throttling. Please do correct me if I have misunderstood something regarding this. > Thanks & Regards, > Ishara Cooray > Senior Software Engineer > Mobile : +9477 262 9512 > WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > On Wed, Sep 12, 2018 at 9:05 AM, Megala Uthayakumar > wrote: > >> Hi Rajith, >> >> Thanks for the response. >> On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan wrote: >> >>> Hi Megala, >>> On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar >>> 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. >>> >> Agree on those points. I was thinking of giving the flexibility to API >> creator to decide on what is the certificate extension attribute, we need >> to get the scope from, may be we can have a optional attibute in API level. >> If the API creator does not want the APIs to checked against scopes, they >> can simply leave the field empty. WDYT? >> >> >>> *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
Re: [Architecture] [AM] Securing APIs using Mutal SSL
Hi Megala, In current authentication handler we set some API Parameters to MessageContext such as CONTEXT, API_VERSION, API, VERSION, RESOURCE, HTTP_METHOD, HOST_NAME, API_PUBLISHER, etc. We will need to do the same with the mutual ssl as well. To subscribe to an api currently we should have an oath application to be used. So in this case even if we do not have any token involved I think still we need let users to subscribe to the api. May be then we can store required subscription related information for a given api. Thanks & Regards, Ishara Cooray Senior Software Engineer Mobile : +9477 262 9512 WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware On Wed, Sep 12, 2018 at 9:05 AM, Megala Uthayakumar wrote: > Hi Rajith, > > Thanks for the response. > On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan wrote: > >> Hi Megala, >> On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar >> 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. >> > Agree on those points. I was thinking of giving the flexibility to API > creator to decide on what is the certificate extension attribute, we need > to get the scope from, may be we can have a optional attibute in API level. > If the API creator does not want the APIs to checked against scopes, they > can simply leave the field empty. WDYT? > > >> >>> *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
Re: [Architecture] [AM] Securing APIs using Mutal SSL
Hi Rajith, Thanks for the response. On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan wrote: > Hi Megala, > On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar > 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. > Agree on those points. I was thinking of giving the flexibility to API creator to decide on what is the certificate extension attribute, we need to get the scope from, may be we can have a optional attibute in API level. If the API creator does not want the APIs to checked against scopes, they can simply leave the field empty. WDYT? > >> *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 > -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [AM] Securing APIs using Mutal SSL
Hi Megala, On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [AM] Securing APIs using Mutal SSL
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. *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. *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 User Story for securing APIs using PKI Certificates .pdf Description: Adobe PDF document ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
