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 <meg...@wso2.com> 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.
>
> [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 <isha...@wso2.com> wrote:
>
>> On Wed, Sep 12, 2018 at 10:08 AM Ishara Cooray <isha...@wso2.com> 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 <raji...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar <meg...@wso2.com>
>>> wrote:
>>>
>>>> Hi Rajith,
>>>>
>>>> Thanks for the response.
>>>> On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan <raji...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Megala,
>>>>> On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar <meg...@wso2.com>
>>>>> 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
>>>
>>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Megala Uthayakumar *| Senior Software Engineer | WSO2 Inc.
> (m) +94 779967122 | (e) meg...@wso2.com
> <http://wso2.com/signature>
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
