[AM] Securing APIs using Mutal SSL

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[AM] Securing APIs using Mutal SSL

Megala Uthayakumar
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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

User Story for securing APIs using PKI Certificates .pdf (69K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Rajith Roshan
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[hidden email]> 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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Megala Uthayakumar
Hi Rajith,

Thanks for the response.
On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan <[hidden email]> wrote:
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[hidden email]> 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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214


--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Ishara Cooray
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 <[hidden email]> wrote:
Hi Rajith,

Thanks for the response.
On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan <[hidden email]> wrote:
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[hidden email]> 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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214


--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Megala Uthayakumar
Hi Ishara,

Thanks for the comments.

On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray <[hidden email]> 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 <[hidden email]> wrote:
Hi Rajith,

Thanks for the response.
On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan <[hidden email]> wrote:
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[hidden email]> 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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214


--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Rajith Roshan
In reply to this post by Megala Uthayakumar


On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar <[hidden email]> wrote:
Hi Rajith,

Thanks for the response.
On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan <[hidden email]> wrote:
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[hidden email]> 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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214


--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Ishara Cooray
On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray <[hidden email]> 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?



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 <[hidden email]> wrote:


On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar <[hidden email]> wrote:
Hi Rajith,

Thanks for the response.
On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan <[hidden email]> wrote:
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[hidden email]> 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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214


--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Megala Uthayakumar
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.

On Thu, Sep 13, 2018 at 5:59 AM Ishara Cooray <[hidden email]> wrote:
On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray <[hidden email]> 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?



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 <[hidden email]> wrote:


On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar <[hidden email]> wrote:
Hi Rajith,

Thanks for the response.
On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan <[hidden email]> wrote:
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[hidden email]> 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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214


--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Megala Uthayakumar | Senior Software Engineer | WSO2 Inc.
(m) +94 779967122 | (e) [hidden email]


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Design Document - Securing APIs using mutual SSL.pdf (75K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Ishara Cooray
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?

Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Fri, Sep 21, 2018 at 2:37 PM Megala Uthayakumar <[hidden email]> wrote:
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.

On Thu, Sep 13, 2018 at 5:59 AM Ishara Cooray <[hidden email]> wrote:
On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray <[hidden email]> 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?



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 <[hidden email]> wrote:


On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar <[hidden email]> wrote:
Hi Rajith,

Thanks for the response.
On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan <[hidden email]> wrote:
Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <[hidden email]> 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 analytics 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.


Thanks.

Regards,
Megala
--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214


--
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122


--
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: <a href="tel:%2B94-71-554-8430" value="+94715548430" target="_blank">+94-717-064-214

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Megala Uthayakumar | Senior Software Engineer | WSO2 Inc.
(m) +94 779967122 | (e) [hidden email]


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Megala Uthayakumar
Hi Ishara,

On Fri, Sep 21, 2018 at 4:52 PM Ishara Cooray <[hidden email]> 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) [hidden email]


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [AM] Securing APIs using Mutal SSL

Megala Uthayakumar
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 <[hidden email]> wrote:
Hi Ishara,

On Fri, Sep 21, 2018 at 4:52 PM Ishara Cooray <[hidden email]> 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) [hidden email]



--
Megala Uthayakumar | Senior Software Engineer | WSO2 Inc.
(m) +94 779967122 | (e) [hidden email]


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture