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
> <http://wso2.com/signature>
>
--
*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
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
<http://wso2.com/signature>
___
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
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. >>>> >>>&g
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
[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
Re: [Architecture] Handling custom claims when generating JWT token using JWT grant type
Yes. I tried to explain the same thing, seems it is confusing. I will simplify it. Thanks. Regards, Megala On Wed, May 30, 2018 at 4:12 PM, Farasath Ahamed wrote: > > > On Wed, May 30, 2018 at 4:04 PM, Megala Uthayakumar > wrote: > >> Resending the missing image >> >> >> > > Regarding "SP Claim Mapping exist with requested attributes" decision, > shouldn't this simply be SP requested claims since we do not care about SP > claim mapping in OIDC flow? > > >> >> >> On Wed, May 30, 2018 at 4:02 PM, Megala Uthayakumar >> wrote: >> >>> *Hi,* >>> >>> *As per the offline discussion with IAM team, following is the agreed >>> design.* >>> >>> >>> >>> *Darshana/Maduranga/Farasath/IAM Team - Please do correct me if I have >>> misunderstood regarding this.* >>> >>> *Thanks.* >>> >>> Regards, >>> Megala >>> >>> On Thu, May 24, 2018 at 9:41 AM, Megala Uthayakumar >>> wrote: >>> >>>> Hi, >>>> >>>> As per the meeting held offline, it was decide to only send the custom >>>> claims when the scope is given as "openid". Sending custom claims that are >>>> not defined in dialect can be supported by adding new claims to openid >>>> dialect and by appending the relevant scopes to "/oidc" resource in config >>>> registry. >>>> >>>> Thanks. >>>> >>>> Regards, >>>> Megala >>>> >>>> On Wed, May 23, 2018 at 2:41 PM, Bhathiya Jayasekara >>> > wrote: >>>> >>>>> Thanks, I just understood the scenario. >>>>> >>>>> Thanks, >>>>> Bhathiya >>>>> >>>>> On Wed, May 23, 2018 at 2:36 PM, Megala Uthayakumar >>>>> wrote: >>>>> >>>>>> Hi Bhathiya, >>>>>> >>>>>> On Wed, May 23, 2018 at 1:05 PM, Bhathiya Jayasekara < >>>>>> bhath...@wso2.com> wrote: >>>>>> >>>>>>> Hi Megala, >>>>>>> >>>>>>> On Wed, May 23, 2018 at 10:11 AM, Megala Uthayakumar < >>>>>>> meg...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I am working on $subject for IS 5.5.0. >>>>>>>> >>>>>>>> When handling custom claims, we do have two options. >>>>>>>> >>>>>>>>1. Handling custom claims as we have handled it in the >>>>>>>>SAML2BearerGrantHandler. >>>>>>>> - Current SAML2BearerGrantHandler converts the claims coming >>>>>>>> from IDP to local claims and then filter out oidc claims only, >>>>>>>> given that >>>>>>>> scope is given as openid. >>>>>>>> 2. Handle relevant custom claims as it is when scope is not >>>>>>>>openid and if the scope is openid filter out the openid scopes as >>>>>>>> we do for >>>>>>>>SAML2BearerGrantHandler >>>>>>>> - If the scope is not openid, add all the custom claims with >>>>>>>> the access token. >>>>>>>> - If the scope is openid, follow the same approach followed >>>>>>>> by SAML2BearerGrantHandler. >>>>>>>> >>>>>>>> I think option 2 is better way to handle this, becuase, >>>>>>>> >>>>>>>> JWT do not restrict the collection of custom claims, hence if we go >>>>>>>> with option 1, customer is expected to select one of the open id >>>>>>>> claims to >>>>>>>> get his claims back in original incoming JWT. >>>>>>>> >>>>>>> >>>>>>> Could you please explain this line further? >>>>>>> >>>>>> In our wso2 IS server, we have predefined list of oidc claims[1], but >>>>>> in JWT we can have custom claims that are not defined in our list. >>>>>> >>>>>> For example, >>>>>> A thrid party identity provider may send a claim with the name >>>>>> "testClai
Re: [Architecture] Handling custom claims when generating JWT token using JWT grant type
Resending the missing image On Wed, May 30, 2018 at 4:02 PM, Megala Uthayakumar wrote: > *Hi,* > > *As per the offline discussion with IAM team, following is the agreed > design.* > > > > *Darshana/Maduranga/Farasath/IAM Team - Please do correct me if I have > misunderstood regarding this.* > > *Thanks.* > > Regards, > Megala > > On Thu, May 24, 2018 at 9:41 AM, Megala Uthayakumar > wrote: > >> Hi, >> >> As per the meeting held offline, it was decide to only send the custom >> claims when the scope is given as "openid". Sending custom claims that are >> not defined in dialect can be supported by adding new claims to openid >> dialect and by appending the relevant scopes to "/oidc" resource in config >> registry. >> >> Thanks. >> >> Regards, >> Megala >> >> On Wed, May 23, 2018 at 2:41 PM, Bhathiya Jayasekara >> wrote: >> >>> Thanks, I just understood the scenario. >>> >>> Thanks, >>> Bhathiya >>> >>> On Wed, May 23, 2018 at 2:36 PM, Megala Uthayakumar >>> wrote: >>> >>>> Hi Bhathiya, >>>> >>>> On Wed, May 23, 2018 at 1:05 PM, Bhathiya Jayasekara >>> > wrote: >>>> >>>>> Hi Megala, >>>>> >>>>> On Wed, May 23, 2018 at 10:11 AM, Megala Uthayakumar >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I am working on $subject for IS 5.5.0. >>>>>> >>>>>> When handling custom claims, we do have two options. >>>>>> >>>>>>1. Handling custom claims as we have handled it in the >>>>>>SAML2BearerGrantHandler. >>>>>> - Current SAML2BearerGrantHandler converts the claims coming >>>>>> from IDP to local claims and then filter out oidc claims only, >>>>>> given that >>>>>> scope is given as openid. >>>>>> 2. Handle relevant custom claims as it is when scope is not >>>>>>openid and if the scope is openid filter out the openid scopes as we >>>>>> do for >>>>>>SAML2BearerGrantHandler >>>>>> - If the scope is not openid, add all the custom claims with >>>>>> the access token. >>>>>> - If the scope is openid, follow the same approach followed by >>>>>> SAML2BearerGrantHandler. >>>>>> >>>>>> I think option 2 is better way to handle this, becuase, >>>>>> >>>>>> JWT do not restrict the collection of custom claims, hence if we go >>>>>> with option 1, customer is expected to select one of the open id claims >>>>>> to >>>>>> get his claims back in original incoming JWT. >>>>>> >>>>> >>>>> Could you please explain this line further? >>>>> >>>> In our wso2 IS server, we have predefined list of oidc claims[1], but >>>> in JWT we can have custom claims that are not defined in our list. >>>> >>>> For example, >>>> A thrid party identity provider may send a claim with the name >>>> "testClaim" with its JWT token and the service provider may expect the same >>>> claim with the same name, but this cannot be done in our case, as we only >>>> pass the predefined set of oidc claims to service provider. >>>> >>>> >>>>> And in the subject you meant generating access token (but not JWT >>>>> token) right? >>>>> >>>> Self contained access token, which is a JWT token. [2] >>>> >>>> >>>>> >>>>> Thanks, >>>>> Bhathiya >>>>> >>>> >>>> [1] https://docs.wso2.com/display/IS550/Configuring+Claims+f >>>> or+an+Identity+Provider#ConfiguringClaimsforanIdentityProvid >>>> er-MappingconfiguredclaimstoanOpenIDConnectclaim >>>> [2] https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens >>>> <https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens> >>>> >>>> >>>> -- >>>> Megala Uthayakumar >>>> >>>> Senior Software Engineer >>>> Mobile : 0779967122 >>>> >>> >>> >>> >>> -- >>> *Bhathiya Jayasekara* >>> *Associate Technical Lead,* >>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>> >>> *Phone: +94715478185* >>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>> <http://www.linkedin.com/in/bhathiyaj>* >>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>> *Blog: http://movingaheadblog.blogspot.com >>> <http://movingaheadblog.blogspot.com/>* >>> >> >> >> >> -- >> Megala Uthayakumar >> >> Senior Software Engineer >> Mobile : 0779967122 >> > > > > -- > Megala Uthayakumar > > Senior Software Engineer > Mobile : 0779967122 > -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Handling custom claims when generating JWT token using JWT grant type
*Hi,* *As per the offline discussion with IAM team, following is the agreed design.* *Darshana/Maduranga/Farasath/IAM Team - Please do correct me if I have misunderstood regarding this.* *Thanks.* Regards, Megala On Thu, May 24, 2018 at 9:41 AM, Megala Uthayakumar wrote: > Hi, > > As per the meeting held offline, it was decide to only send the custom > claims when the scope is given as "openid". Sending custom claims that are > not defined in dialect can be supported by adding new claims to openid > dialect and by appending the relevant scopes to "/oidc" resource in config > registry. > > Thanks. > > Regards, > Megala > > On Wed, May 23, 2018 at 2:41 PM, Bhathiya Jayasekara > wrote: > >> Thanks, I just understood the scenario. >> >> Thanks, >> Bhathiya >> >> On Wed, May 23, 2018 at 2:36 PM, Megala Uthayakumar >> wrote: >> >>> Hi Bhathiya, >>> >>> On Wed, May 23, 2018 at 1:05 PM, Bhathiya Jayasekara >>> wrote: >>> >>>> Hi Megala, >>>> >>>> On Wed, May 23, 2018 at 10:11 AM, Megala Uthayakumar >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I am working on $subject for IS 5.5.0. >>>>> >>>>> When handling custom claims, we do have two options. >>>>> >>>>>1. Handling custom claims as we have handled it in the >>>>>SAML2BearerGrantHandler. >>>>> - Current SAML2BearerGrantHandler converts the claims coming >>>>> from IDP to local claims and then filter out oidc claims only, >>>>> given that >>>>> scope is given as openid. >>>>> 2. Handle relevant custom claims as it is when scope is not >>>>>openid and if the scope is openid filter out the openid scopes as we >>>>> do for >>>>>SAML2BearerGrantHandler >>>>> - If the scope is not openid, add all the custom claims with >>>>> the access token. >>>>> - If the scope is openid, follow the same approach followed by >>>>> SAML2BearerGrantHandler. >>>>> >>>>> I think option 2 is better way to handle this, becuase, >>>>> >>>>> JWT do not restrict the collection of custom claims, hence if we go >>>>> with option 1, customer is expected to select one of the open id claims to >>>>> get his claims back in original incoming JWT. >>>>> >>>> >>>> Could you please explain this line further? >>>> >>> In our wso2 IS server, we have predefined list of oidc claims[1], but in >>> JWT we can have custom claims that are not defined in our list. >>> >>> For example, >>> A thrid party identity provider may send a claim with the name >>> "testClaim" with its JWT token and the service provider may expect the same >>> claim with the same name, but this cannot be done in our case, as we only >>> pass the predefined set of oidc claims to service provider. >>> >>> >>>> And in the subject you meant generating access token (but not JWT >>>> token) right? >>>> >>> Self contained access token, which is a JWT token. [2] >>> >>> >>>> >>>> Thanks, >>>> Bhathiya >>>> >>> >>> [1] https://docs.wso2.com/display/IS550/Configuring+Claims+f >>> or+an+Identity+Provider#ConfiguringClaimsforanIdentityProvid >>> er-MappingconfiguredclaimstoanOpenIDConnectclaim >>> [2] https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens >>> <https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens> >>> >>> >>> -- >>> Megala Uthayakumar >>> >>> Senior Software Engineer >>> Mobile : 0779967122 >>> >> >> >> >> -- >> *Bhathiya Jayasekara* >> *Associate Technical Lead,* >> *WSO2 inc., http://wso2.com <http://wso2.com>* >> >> *Phone: +94715478185* >> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >> <http://www.linkedin.com/in/bhathiyaj>* >> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >> *Blog: http://movingaheadblog.blogspot.com >> <http://movingaheadblog.blogspot.com/>* >> > > > > -- > Megala Uthayakumar > > Senior Software Engineer > Mobile : 0779967122 > -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Handling custom claims when generating JWT token using JWT grant type
Hi, As per the meeting held offline, it was decide to only send the custom claims when the scope is given as "openid". Sending custom claims that are not defined in dialect can be supported by adding new claims to openid dialect and by appending the relevant scopes to "/oidc" resource in config registry. Thanks. Regards, Megala On Wed, May 23, 2018 at 2:41 PM, Bhathiya Jayasekara wrote: > Thanks, I just understood the scenario. > > Thanks, > Bhathiya > > On Wed, May 23, 2018 at 2:36 PM, Megala Uthayakumar > wrote: > >> Hi Bhathiya, >> >> On Wed, May 23, 2018 at 1:05 PM, Bhathiya Jayasekara >> wrote: >> >>> Hi Megala, >>> >>> On Wed, May 23, 2018 at 10:11 AM, Megala Uthayakumar >>> wrote: >>> >>>> Hi All, >>>> >>>> I am working on $subject for IS 5.5.0. >>>> >>>> When handling custom claims, we do have two options. >>>> >>>>1. Handling custom claims as we have handled it in the >>>>SAML2BearerGrantHandler. >>>> - Current SAML2BearerGrantHandler converts the claims coming >>>> from IDP to local claims and then filter out oidc claims only, given >>>> that >>>> scope is given as openid. >>>> 2. Handle relevant custom claims as it is when scope is not >>>>openid and if the scope is openid filter out the openid scopes as we do >>>> for >>>>SAML2BearerGrantHandler >>>> - If the scope is not openid, add all the custom claims with the >>>> access token. >>>> - If the scope is openid, follow the same approach followed by >>>> SAML2BearerGrantHandler. >>>> >>>> I think option 2 is better way to handle this, becuase, >>>> >>>> JWT do not restrict the collection of custom claims, hence if we go >>>> with option 1, customer is expected to select one of the open id claims to >>>> get his claims back in original incoming JWT. >>>> >>> >>> Could you please explain this line further? >>> >> In our wso2 IS server, we have predefined list of oidc claims[1], but in >> JWT we can have custom claims that are not defined in our list. >> >> For example, >> A thrid party identity provider may send a claim with the name >> "testClaim" with its JWT token and the service provider may expect the same >> claim with the same name, but this cannot be done in our case, as we only >> pass the predefined set of oidc claims to service provider. >> >> >>> And in the subject you meant generating access token (but not JWT token) >>> right? >>> >> Self contained access token, which is a JWT token. [2] >> >> >>> >>> Thanks, >>> Bhathiya >>> >> >> [1] https://docs.wso2.com/display/IS550/Configuring+Claims+f >> or+an+Identity+Provider#ConfiguringClaimsforanIdentityProvid >> er-MappingconfiguredclaimstoanOpenIDConnectclaim >> [2] https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens >> <https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens> >> >> >> -- >> Megala Uthayakumar >> >> Senior Software Engineer >> Mobile : 0779967122 >> > > > > -- > *Bhathiya Jayasekara* > *Associate Technical Lead,* > *WSO2 inc., http://wso2.com <http://wso2.com>* > > *Phone: +94715478185* > *LinkedIn: http://www.linkedin.com/in/bhathiyaj > <http://www.linkedin.com/in/bhathiyaj>* > *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* > *Blog: http://movingaheadblog.blogspot.com > <http://movingaheadblog.blogspot.com/>* > -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Handling custom claims when generating JWT token using JWT grant type
Hi Bhathiya, On Wed, May 23, 2018 at 1:05 PM, Bhathiya Jayasekara wrote: > Hi Megala, > > On Wed, May 23, 2018 at 10:11 AM, Megala Uthayakumar > wrote: > >> Hi All, >> >> I am working on $subject for IS 5.5.0. >> >> When handling custom claims, we do have two options. >> >>1. Handling custom claims as we have handled it in the >>SAML2BearerGrantHandler. >> - Current SAML2BearerGrantHandler converts the claims coming from >> IDP to local claims and then filter out oidc claims only, given that >> scope >> is given as openid. >> 2. Handle relevant custom claims as it is when scope is not openid >>and if the scope is openid filter out the openid scopes as we do for >>SAML2BearerGrantHandler >> - If the scope is not openid, add all the custom claims with the >> access token. >> - If the scope is openid, follow the same approach followed by >> SAML2BearerGrantHandler. >> >> I think option 2 is better way to handle this, becuase, >> >> JWT do not restrict the collection of custom claims, hence if we go with >> option 1, customer is expected to select one of the open id claims to get >> his claims back in original incoming JWT. >> > > Could you please explain this line further? > In our wso2 IS server, we have predefined list of oidc claims[1], but in JWT we can have custom claims that are not defined in our list. For example, A thrid party identity provider may send a claim with the name "testClaim" with its JWT token and the service provider may expect the same claim with the same name, but this cannot be done in our case, as we only pass the predefined set of oidc claims to service provider. > And in the subject you meant generating access token (but not JWT token) > right? > Self contained access token, which is a JWT token. [2] > > Thanks, > Bhathiya > [1] https://docs.wso2.com/display/IS550/Configuring+Claims+f or+an+Identity+Provider#ConfiguringClaimsforanIdentityProvid er-MappingconfiguredclaimstoanOpenIDConnectclaim [2] https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens <https://docs.wso2.com/display/IS550/Self-contained+Access+Tokens> -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Handling custom claims when generating JWT token using JWT grant type
Hi All, I am working on $subject for IS 5.5.0. When handling custom claims, we do have two options. 1. Handling custom claims as we have handled it in the SAML2BearerGrantHandler. - Current SAML2BearerGrantHandler converts the claims coming from IDP to local claims and then filter out oidc claims only, given that scope is given as openid. 2. Handle relevant custom claims as it is when scope is not openid and if the scope is openid filter out the openid scopes as we do for SAML2BearerGrantHandler - If the scope is not openid, add all the custom claims with the access token. - If the scope is openid, follow the same approach followed by SAML2BearerGrantHandler. I think option 2 is better way to handle this, becuase, JWT do not restrict the collection of custom claims, hence if we go with option 1, customer is expected to select one of the open id claims to get his claims back in original incoming JWT. Appreciate your input on this. What is the correct way to move forward? Thanks. Regards, Megala -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning
> mandatory claims that are missing in the request as well as they need to >>>> provide a valid password. >>>> >>>> >>>> *3. How multiple social accounts can be associated*This applies when >>>> we support multiple social signup options (Facebook, Google, Twitter etc). >>>> When a user has already signed up with one social account, after some >>>> time, he/she again tries to signup using a different account. >>>> As different social accounts use differnt ids for users, there shoul be >>>> a mechanism to map the values to the existing user. >>>> >>>> As a solution for this we can allow users to add their other social >>>> account details in the user profile. So, when the user is trying to sign up >>>> using another account he/she will be logged into the existing account. >>>> >>>> *4. What are the user claims that we should retrieve from the social >>>> account and do we allow users to edit those claims.* >>>> As we show the claims that are retrieved from the signup request, have >>>> to decide whether we allow users to modify those details. As per the >>>> discussion [1] we only allow to edit the exact claims that can be edited in >>>> the user profile. >>>> >>>> I have written the use cases that will be involved in this use case and >>>> attached herewith. >>>> https://docs.google.com/document/d/1rNnQj_KMJO5ZLJQE_2F9Ezk_ >>>> WqC-IAq2vmaJ5bk5j4k/edit?usp=sharing >>>> >>>> Any ideas suggestions are highly appreciated. >>>> >>>> [1] Updated invitation: IS Flash PC @ Mon Apr 9, 2018 1:45pm - 2:30pm >>>> (IST) (Rapid Response Group) >>>> >>>> Thanks and Regards, >>>> Menaka >>>> -- >>>> *Menaka Jayawardena* >>>> Software Engineer >>>> WSO2 Inc. >>>> >>>> Phone: +94 71 350 5470 >>>> LinkedIn : https://lk.linkedin.com/in/menakajayawardena >>>> Blog : https://menakamadushanka.wordpress.com/ >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : nuw...@wso2.com >>> Phone : +94 777 775 729 >>> >> >> >> >> -- >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile: *+94 77 7776950* >> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >> <http://www.linkedin.com/in/johann-nallathamby>* >> Medium: *https://medium.com/@johann_nallathamby >> <https://medium.com/@johann_nallathamby>* >> Twitter: *@dj_nallaa* >> > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Json Schema Validation
Hi Nuwan/Sanjeewa/APIM Team,
Since we need a way to keep track of whether json schema validation is
enabled or not for a particular API, shall we go ahead with a regsitry
property for this, as we did for publisher access control feature before?
If we are going with an attribute, we may need to modify the RXT and there
will be a migration for old APIs. What would be the recommended way of
doing this?
Thanks.
Regards,
Megala
On Thu, Mar 15, 2018 at 10:39 PM, Chamin Dias wrote:
> Hi,
>
> On Thu, Mar 15, 2018 at 2:44 PM, Sanjeewa Malalgoda
> wrote:
>
>> Hi Sivaramya,
>> Its always good to start with complete swagger sample hosted by swagger.
>> If you look at APIs deployed here then different paths accept different
>> request payloads.
>> How are we adding resource accordingly? Is that local entry UUID passed
>> to class mediator knows resource specific schema? If so there can be
>> multiple entries per API.
>>
>> Also lets think about cleaning local entries when we disable this.
>> Otherwise they will be remain in gateways.
>>
>> [1]https://github.com/OAI/OpenAPI-Specification/blob/master/
>> examples/v2.0/json/petstore-simple.json
>>
>> Thanks,
>> sanjeewa.
>>
>> On Wed, Mar 14, 2018 at 4:39 PM, Sivaramya Sivanathan > > wrote:
>>
>>> Hi all,
>>>
>>> Currently, I'm working on the Json Schema Validation for API manager. When
>>> we execute a API request, we need to do the Json schema validation so that
>>> we can reduce the backend failures and also we can protect the gateways.
>>> For this feature the proposed method is as follows,
>>>
>>>-
>>>
>>>Add the Json schema to the swagger file as mentioned below, so that
>>>we can validate the request using the swagger file.
>>>
>>> *"parameters": [*
>>>
>>> * {*
>>>
>>> *"name": "Product",*
>>>
>>> *"description": "A product from the catalog",*
>>>
>>> *"required": false,*
>>>
>>> *"in": "body",*
>>>
>>> *"schema": {*
>>>
>>> * "type": "object",*
>>>
>>> * "properties": {*
>>>
>>> *"id": {*
>>>
>>> * "type": "number",*
>>>
>>> * “Description”: “The unique identifier for a product”*
>>>
>>> *},*
>>>
>>> *"name": {*
>>>
>>> * "type": "string",*
>>>
>>> * “Description”: “Name of the product”*
>>>
>>> *},*
>>>
>>> * "price": {*
>>>
>>> * "type": "number",*
>>>
>>> * “minimum”: 0*
>>>
>>> * }*
>>>
>>> *}*
>>>
>>> * }*
>>>
>>> *],*
>>>
>>>
>>>- Add a new check-box to enable the json-schema in UI in the
>>>publisher level.
>>>- If check-box enabled, at the point of generating API synapse
>>>configuration, we can add the schema to a local entry which the name of
>>> the
>>>local entry will be UUID + api+ resource version.
>>>- We can add a property to hold the local entry name related with
>>>UUID and add a class mediator inside each resource definition.
>>>- Class mediator should make use of that property to get the schema
>>>
>>> In this situation, will there be many local entries per API? Do we have
> any mechanism to handle those kind of scenarios?
>
> Regards,
>>> Sivaramya Sivanathan
>>> Associate Software Engineer | WSO2
>>> Tel: 0770874960 <077%20087%204960>
>>> WSO2 Inc : http://wso2.org
>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.org&sa=D&sntz=1&usg=AFQjCNE_eTDfyl2ibPcq0hcXvRDNVuQmMg>
>>> LinkedIn | www.linkedin.com/in/sivaramya
>>>
>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <+94%2071%20306%208779>
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Chamin Dias
> Mobile : 0716097455
> Email : cham...@wso2.com
> LinkedIn : https://www.linkedin.com/in/chamindias
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Megala Uthayakumar
Senior Software Engineer
Mobile : 0779967122
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Json Schema Validation
I just had a looked at the current code, and seems we are building the
message on-demand[1]. In that case, the relevant message will not be build
until it goes to the content-aware mediator level. Hence I think we can go
ahead with the class mediator based approach.
[1]
https://github.com/wso2/wso2-synapse/blob/v2.1.7-wso2v46/modules/core/src/main/java/org/apache/synapse/mediators/AbstractListMediator.java#L93
Thanks.
Regards,
Megala
On Thu, Mar 15, 2018 at 10:13 AM, Shazni Nazeer wrote:
> I'm not opposed to using the existing validate mediator.
>
> But won't it avoid building the message one extra time by using a class
> mediator?
>
> On Wed, Mar 14, 2018 at 11:05 PM, Megala Uthayakumar
> wrote:
>
>> Hi Sivaramya,
>>
>> We decided to go for a class mediator without using existing validate
>> mediator to avoid building the message. However, on a second thought, if we
>> add the class mediator inside the insequence of the resource as below,
>>
>> * *
>> * *
>> * *
>> * > * expression="get-property('SYSTEM_TIME')"/>*
>>
>>
>> AFAIK in synapse level, it will check whether there are any mediators in
>> the in-sequence that is content-aware. If it is content-aware, in synapse
>> level relevant message will be build before starting the in-Sequence. In
>> that case, since we are using the property mediator in insequence, which is
>> content-aware, regardless of whether our class mediator is content-aware or
>> not, the relevant message will be built. In that case, main reason for
>> creating a custom class mediator is invalidated. So how are we going to
>> handle this?
>>
>> If we are ok to build the message before JsonSchemaValidation, can't we
>> use the existing validate mediator itself? WDYT?
>>
>> Thanks.
>>
>> Regards,
>> Megala
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Shazni Nazeer
>
> Mob : +94 37331
> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>
> Blogs :
>
> https://medium.com/@mshazninazeer
> http://shazninazeer.blogspot.com
>
> <http://wso2.com/signature>
>
--
Megala Uthayakumar
Senior Software Engineer
Mobile : 0779967122
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Json Schema Validation
Hi Sivaramya, We decided to go for a class mediator without using existing validate mediator to avoid building the message. However, on a second thought, if we add the class mediator inside the insequence of the resource as below, * * * * * * * * AFAIK in synapse level, it will check whether there are any mediators in the in-sequence that is content-aware. If it is content-aware, in synapse level relevant message will be build before starting the in-Sequence. In that case, since we are using the property mediator in insequence, which is content-aware, regardless of whether our class mediator is content-aware or not, the relevant message will be built. In that case, main reason for creating a custom class mediator is invalidated. So how are we going to handle this? If we are ok to build the message before JsonSchemaValidation, can't we use the existing validate mediator itself? WDYT? Thanks. Regards, Megala ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Improving audit logs related with user management tasks
Hi Sanjeewa/Tharindu and all,
I have done some reading on this area and has come-up with the doc based on
guidelines.
Following is the summary based on my reading,
GDPR does not directly mention the recommendations related with logging and
monitoring. However based on various points given under the regulations, we
could derive some of the important guidelines that need to be followed
while doing audit logging. Most of OWASP’s guidelines for logging and
monitoring agrees with the logging and monitoring requirement for GDPR.
Following are the some most important points while doing the auditing.
1. Audit logs should have the details of modifications and retrieval
tasks done on personal data. We may have different log levels for this. For
modification, we could give higher severity and for retrieval , we could
give lower severity.
2. Each audit log should include who, where, whom and what
Based on this following are the most import improvements that need to be
included.
- Need to introduce logs for all the modification and viewing purpose.
Importantly, we need to log all the activities related with the users who
have adminstrator priviledges.
- Need to decide on introducing different severity levels for audit logs
- Make sure that each log entry include who, where, why and what.
As a starting point, I will be investigating on feasiibility of impoving
current UserAuditLogger to accomadate all these improvements. Appreciate
your suggestions on this.
[1]
https://docs.google.com/document/d/1hVewKDQ_-vhnkYX1ChC6lIBoEfuC-E2r43Tbd6eZL4g/edit?usp=sharing
Thanks
,
Regards,
Megala
On Wed, Mar 14, 2018 at 9:35 AM, Sanjeewa Malalgoda
wrote:
> There are some recommendations related to GDPR and it would be great if we
> can search little bit. Then we can figure out what we need to do
> additionally support GDPR requirements. Log access to personal data is
> something everyone discuss these days. As recommended every read operation
> on a personal data record should be logged, so that user/admin know who
> accessed what and for what purpose.
>
> Sagara, Ruwan may provide better guidance.
>
> Thanks,
> sanjeewa.
>
> On Wed, Mar 14, 2018 at 9:26 AM, Megala Uthayakumar
> wrote:
>
>> Hi Tharindu,
>>
>> Thanks for the response. I think we could define a new format, given that
>> it improves the search based on logs. I will go through provided docs.
>>
>> Thanks.
>>
>> Regards,
>> Megala
>>
>> On Tue, Mar 13, 2018 at 5:19 PM, Tharindu Edirisinghe > > wrote:
>>
>>> Hi Megala,
>>>
>>> For improving the search friendliness, are you defining a new format for
>>> the audit log entry ?
>>>
>>> Currently we have following format.
>>>
>>> | | | |
>>>
>>> Eg: INFO {AUDIT_LOG}- Initiator : admin@carbon.super | Action : Add
>>> User | Target : newuser | Data : { Roles : } | Result : Success
>>>
>>> In OWASP Top 10 list of vulnerabilities for 2017 [1], "Logging &
>>> Monitoring" is newly introduced due to it's importance.
>>>
>>> You can refer [2] for more information on this and accommodate the
>>> recommendations in your improvements.
>>>
>>> [1] https://www.owasp.org/images/7/72/OWASP_Top_10-2017_(en).pdf.pdf
>>> [2] https://www.owasp.org/index.php/Logging_Cheat_Sheet
>>>
>>> Regards,
>>> TharinduE
>>>
>>> On Tue, Mar 13, 2018 at 4:03 PM, Megala Uthayakumar
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am working on improving audit logs related with user management
>>>> tasks. Currently we have audit logs upto some extent, however it could be
>>>> further improved. So in this improvement I will focusing on following tasks
>>>>
>>>>1. Modifying the current audit logs, so that they will give better
>>>>information regarding the user management tasks done by a user.
>>>>2. Focusing on search friendly logs, which the search based on a
>>>>regex will return the relevant results expected by the server admin.
>>>>3. Currently we have not implemented some methods
>>>>from AbstractUserOperationEventListener in UserMgtAuditLogger[1],
>>>>the event listener for logging audit logs related with user management.
>>>> So
>>>>will be focusing on implementing the other relevant methods to add the
>>>>meaningful audit logs.
>>>>4. Focusing on solving the issues that are reported already related
>>>>with user-mgt related audit logs[2].
>>>>
>>>> I have cre
Re: [Architecture] Improving audit logs related with user management tasks
Hi Tharindu,
Thanks for the response. I think we could define a new format, given that
it improves the search based on logs. I will go through provided docs.
Thanks.
Regards,
Megala
On Tue, Mar 13, 2018 at 5:19 PM, Tharindu Edirisinghe
wrote:
> Hi Megala,
>
> For improving the search friendliness, are you defining a new format for
> the audit log entry ?
>
> Currently we have following format.
>
> | | | |
>
> Eg: INFO {AUDIT_LOG}- Initiator : admin@carbon.super | Action : Add User
> | Target : newuser | Data : { Roles : } | Result : Success
>
> In OWASP Top 10 list of vulnerabilities for 2017 [1], "Logging &
> Monitoring" is newly introduced due to it's importance.
>
> You can refer [2] for more information on this and accommodate the
> recommendations in your improvements.
>
> [1] https://www.owasp.org/images/7/72/OWASP_Top_10-2017_(en).pdf.pdf
> [2] https://www.owasp.org/index.php/Logging_Cheat_Sheet
>
> Regards,
> TharinduE
>
> On Tue, Mar 13, 2018 at 4:03 PM, Megala Uthayakumar
> wrote:
>
>> Hi All,
>>
>> I am working on improving audit logs related with user management tasks.
>> Currently we have audit logs upto some extent, however it could be further
>> improved. So in this improvement I will focusing on following tasks
>>
>>1. Modifying the current audit logs, so that they will give better
>>information regarding the user management tasks done by a user.
>>2. Focusing on search friendly logs, which the search based on a
>>regex will return the relevant results expected by the server admin.
>>3. Currently we have not implemented some methods
>>from AbstractUserOperationEventListener in UserMgtAuditLogger[1], the
>>event listener for logging audit logs related with user management. So
>> will
>>be focusing on implementing the other relevant methods to add the
>>meaningful audit logs.
>>4. Focusing on solving the issues that are reported already related
>>with user-mgt related audit logs[2].
>>
>> I have created a user story doc for this improvement[3] . Appreciate your
>> comments and suggestions on this to further improve the audit logs related
>> with user management.
>>
>> [1] https://github.com/wso2/carbon-identity-framework/blob/
>> 5.11.x/components/user-mgt/org.wso2.carbon.user.mgt/src/
>> main/java/org/wso2/carbon/user/mgt/listeners/UserMgtAuditLogger.java
>> [2] https://github.com/wso2/product-is/issues?utf8=%E2%9C%93
>> &q=is%3Aissue+is%3Aopen+audit
>> [3] https://docs.google.com/document/d/1Ls0VuLsJaQtQAPgR3Nkw
>> trcbFUvVZuPW_gXA7bV5mmo/edit?usp=sharing
>>
>> Thanks.
>>
>> Regards,
>> Megala
>> --
>> Megala Uthayakumar
>>
>> Senior Software Engineer
>> Mobile : 0779967122
>>
>
>
>
> --
>
> Tharindu Edirisinghe
> Senior Software Engineer | WSO2 Inc
> Platform Security Team
> Blog : http://tharindue.blogspot.com
> mobile : +94 775181586 <+94%2077%20518%201586>
>
--
Megala Uthayakumar
Senior Software Engineer
Mobile : 0779967122
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Improving audit logs related with user management tasks
Hi All, I am working on improving audit logs related with user management tasks. Currently we have audit logs upto some extent, however it could be further improved. So in this improvement I will focusing on following tasks 1. Modifying the current audit logs, so that they will give better information regarding the user management tasks done by a user. 2. Focusing on search friendly logs, which the search based on a regex will return the relevant results expected by the server admin. 3. Currently we have not implemented some methods from AbstractUserOperationEventListener in UserMgtAuditLogger[1], the event listener for logging audit logs related with user management. So will be focusing on implementing the other relevant methods to add the meaningful audit logs. 4. Focusing on solving the issues that are reported already related with user-mgt related audit logs[2]. I have created a user story doc for this improvement[3] . Appreciate your comments and suggestions on this to further improve the audit logs related with user management. [1] https://github.com/wso2/carbon-identity-framework/blob/5.11.x/components/user-mgt/org.wso2.carbon.user.mgt/src/main/java/org/wso2/carbon/user/mgt/listeners/UserMgtAuditLogger.java [2] https://github.com/wso2/product-is/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+audit [3] https://docs.google.com/document/d/1Ls0VuLsJaQtQAPgR3NkwtrcbFUvVZuPW_gXA7bV5mmo/edit?usp=sharing Thanks. Regards, Megala -- Megala Uthayakumar Senior Software Engineer Mobile : 0779967122 User Story for Improving Audit Logs of UserManagement Tasks.pdf Description: Adobe PDF document ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4
Hi, I tested followings - Mobile Device and App Management Quick Start guide with android. - User Management and Role Management functionalities through device management console. - Android device enrollment as a normal user. Tested with some operations as well. - Android sense enrollment as a normal user. Was able to see the relevant graphs. Did not encounter any issues. Hence, [+] Stable - Go ahead and release. Thanks. Regards, Megala On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera wrote: > Hi Devs, > > We are pleased to announce the release candidate version 4 of WSO2 IoT Server > 3.1.0. > > Please download, test the product and vote. Vote will be open for 72 hours > or as needed. > > Known issues : https://github.com/wso2/product-iots/issues-RC4 > <https://github.com/wso2/product-iots/issues?q=is%3Aopen+is%3Aissue+label%3A3.1.0-RC3> > > Source and binary distribution files: > https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4 > > The tag to be voted upon: > https://github.com/wso2/product-iots/tree/v3.1.0-RC4 > > Please vote as follows. > [+] Stable - go ahead and release > [-] Broken - do not release (explain why) > > Thank you > > Regards, > -- > *Milan Perera *| Senior Software Engineer > WSO2, Inc | lean. enterprise. middleware. > #20, Palm Grove, Colombo 03, Sri Lanka > Mobile: +94 77 309 7088 | Work: +94 11 214 5345 > Email: mi...@wso2.com | Web: www.wso2.com > <http://lk.linkedin.com/in/milanharinduperera> > <https://wso2.com/signature> > -- Megala Uthayakumar Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] [VOTE] Release WSO2 Enterprise Mobility Manager 2.2.0 RC2
Hi All, I tested the SSO scenario in super-tenant mode and tenant mode as admin. Found no any major issues. Hence, [+] - stable - go ahead and release. Thanks. Regards, Megala. On Thu, Dec 1, 2016 at 11:36 AM, Hasunie Adikari wrote: > Hi All, > > I have tested following scenarios. > > 1. Windows Device enrollment. > 2. Add windows operations > 3. Create windows policy and apply to the device. > 4. Edit Windows policy and done apply changes. > 5. Create more policies and set priority and then apply to the device. > 6. tested notification pane. > > [+] - stable - go ahead and release. > > Thanks > Hasunie > > On Thu, Dec 1, 2016 at 10:41 AM, Geeth Munasinghe wrote: > >> Hi all, >> >> Tested following scenarios. >> >> >>1. Android device enrollment. >>2. User and role creation and assigning permission. >>3. Sending email with user invite. >>4. Create/Edit policy >>5. Applying policy to device. >>6. Reapplying changed policy. >>7. Add few operations. >> >> [+] - Stable - go ahead and release. >> >> Thanks >> Geeth >> >> On Thu, Dec 1, 2016 at 10:26 AM, Inosh Perera wrote: >> >>> Hi all, >>> >>> I have tested FCM together with Android enrollment and operation >>> sending, functionality works well. >>> >>> [+] Stable - go ahead and release >>> >>> Regards, >>> Inosh >>> >>> On Wed, Nov 30, 2016 at 3:55 PM, Charitha Goonetilleke < >>> charit...@wso2.com> wrote: >>> >>>> Hi All, >>>> >>>> I have enrolled Android device and tested basic functionality. >>>> >>>> [+] Stable - go ahead and release >>>> >>>> Thanks & Regards, >>>> /charithag >>>> >>>> On Tue, Nov 29, 2016 at 9:50 PM, Harshan Liyanage >>>> wrote: >>>> >>>>> Hi Devs, >>>>> >>>>> This is the release candidate of WSO2 Enterprise Mobility Manager 2.2. >>>>> 0. >>>>> >>>>> Please download EMM 2.2.0 RC2 and test the functionality and vote. >>>>> Vote will be open for 72 hours or as needed. >>>>> Know issues: https://wso2.org/jira/issues/?filter=13384 >>>>> Fixes provided : https://wso2.org/jira/issues/?filter=13582 >>>>> <https://wso2.org/jira/issues/?filter=13582> >>>>> >>>>> Source & binary distribution files: >>>>> https://github.com/wso2/product-emm/releases/tag/v2.2.0-RC2 >>>>> >>>>> The tag to be voted upon: >>>>> https://github.com/wso2/product-emm/tree/release-2.2.0-RC2 >>>>> >>>>> >>>>> [+] Stable - go ahead and release >>>>> [-] Broken - do not release (explain why) >>>>> >>>>> Thanks and Regards, >>>>> >>>>> >>>>> Harshan Liyanage >>>>> EMM/IoT TG >>>>> Mobile: *+94765672894* >>>>> Email: hars...@wso2.com >>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>> lean.enterprise.middleware. >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Charitha Goonetilleke* >>>> Software Engineer >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 77 751 3669 <%2B94777513669> >>>> Twitter:@CharithaWs <https://twitter.com/CharithaWs>, fb: charithag >>>> <https://www.facebook.com/charithag>, linkedin: charithag >>>> <http://www.linkedin.com/in/charithag> >>>> >>>> <http://wso2.com/signature> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Inosh Perera >>> Senior Software Engineer, WSO2 Inc. >>> Tel: 077813 7285, 0785293686 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *G. K. S. Munasinghe* >> *Senior Software Engineer,* >> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >> *lean.enterprise.middleware.* >> >> email: ge...@wso2.com >> phone:(+94) 777911226 <+94%2077%20791%201226> >> >> <http://wso2.com/signature> >> >> ___ >> Dev mailing list >> d...@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Hasunie Adikari* > Software Engineer > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > blog http://hasuniea.blogspot.com > Mobile:+94713350904 <+94%2071%20335%200904> > > ___ > Dev mailing list > d...@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Megala Uthayakumar Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [Dev] WSO2 Dashboard Server 2.1.0-Alpha Released!
WSO2 Dashboard Server 2.1.0-Alpha Released! WSO2 Dashboard Server team is pleased to announce the release of WSO2 Dashboard Server 2.1.0 Alpha. This release comes with the following bug fixes, improvements and tasks. You can download the distribution from [1] and view the documentation at [2]. Bug - [UES-990 <https://wso2.org/jira/browse/UES-990>] - All the query params get appended to the url when navigating via hierarchical menu - [UES-1016 <https://wso2.org/jira/browse/UES-1016>] - Tenant ID is always super tenant ID in Gadget Generation Wizard - [UES-1018 <https://wso2.org/jira/browse/UES-1018>] - DS Console differs from the WSO2 theme - [UES-1022 <https://wso2.org/jira/browse/UES-1022>] - Product version in footer is incorrect - [UES-1023 <https://wso2.org/jira/browse/UES-1023>] - Create view menu rendered incorrectly - [UES-1028 <https://wso2.org/jira/browse/UES-1028>] - Creating gadgets in third-party store - Thumbnail image does not show Improvement - [UES-970 <https://wso2.org/jira/browse/UES-970>] - Add download functionality to gadgets listed - [UES-995 <https://wso2.org/jira/browse/UES-995>] - Having a landing page for a dashboard is optional - [UES-1003 <https://wso2.org/jira/browse/UES-1003>] - Modify the ES extension to not allow the assets to be editable in published asset - [UES-1010 <https://wso2.org/jira/browse/UES-1010>] - Add shindig features to get the hostName,port and tenant domain - [UES-1012 <https://wso2.org/jira/browse/UES-1012>] - Store the theme level properties to dashboard.json and retrieve these theme properties while rendering the page - [UES-1014 <https://wso2.org/jira/browse/UES-1014>] - Add new gadget/layout button at the end of the gadget listing and layout listings when user designs dashboard - [UES-1015 <https://wso2.org/jira/browse/UES-1015>] - Dashboard page loading icon for embeddable gadget feature Task - [UES-1005 <https://wso2.org/jira/browse/UES-1005>] - Provide common repository for js libraries to use in gadgets - [UES-1006 <https://wso2.org/jira/browse/UES-1006>] - Dashboard page loading icon to show after all gadgets are loaded - [UES-1007 <https://wso2.org/jira/browse/UES-1007>] - Fixed the issue in PDF download feature in firefox browser - [UES-1008 <https://wso2.org/jira/browse/UES-1008>] - Fixing issues in running the dashboard server with samples - [UES-1029 <https://wso2.org/jira/browse/UES-1029>] - Create Puppet script for Dashboard Server Auto Deployment Reporting Issues Issues can be reported through the Public JIRA <https://wso2.org/jira/browse/UES> project for WSO2 Dashboard Server. [1]- https://github.com/wso2/product-ds/releases/download/v2.1.0-alpha/wso2ds-2.1.0-SNAPSHOT.zip [2]- https://docs.wso2.com/display/DS210/WSO2+Dashboard+Server+Documentation Thanks, Dashboard Server Team. -- Megala Uthayakumar Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Sharing Dashboards that have gadgets with role restriction
Hi Dilan, On Sat, Jun 11, 2016 at 7:09 PM, Dilan Udara Ariyaratne wrote: > Hi Megala / Tanya, > > It would be useful if you can also explain the practical use-cases behind > implementing this feature; > so that it validates the real necessity of having such feature available > on the product. > We implemented this feature based on a real use-case which came from a product team. The real use-case for this feature is follow, When a dashboard has certain set of gadgets which uses the data of the currently logged in user and displays some graphs based on that (Ex - Logs/Usages). There may be a situation where we need the same dashboard in all the tenants so that whenever dashboard is used by different tenants, it uses the relevant data from tenant-user. Due to restricting dashboard per tenant, it requires to create same dashboard in all the tenants and it also requires, the tenants to have all the relevant gadgets in relevant gadget stores. But creating a separate dashboard for each tenant and having the same set of gadgets in relevant gadget stores is very heavy for server run-time and it results in lots of duplicates. So in order to avoid that problem we came up with this feature. > IMO, making a dashboard blindly viewable to any user on any other tenant > (who might even not be interested in viewing such dashboard) may not be a > practical use-case. > We are providing a filter option in dashboard-listing page. So that users can select the relevant filters and only view that are specific to him/her. Thanks. Regards, Megala > Please do correct me, if I have misunderstood anything. > > Regards, > Dilan. > > *Dilan U. Ariyaratne* > Senior Software Engineer > WSO2 Inc. <http://wso2.com/> > Mobile: +94766405580 <%2B94766405580> > lean . enterprise . middleware > > > On Fri, Jun 10, 2016 at 9:46 AM, Tanya Madurapperuma > wrote: > >> Hi Dilini, >> >> On Fri, Jun 10, 2016 at 9:38 AM, Dilini Gunatilake >> wrote: >> >>> Hi Tanya/Megala, >>> >>> Can't we share the anonymous view with other tenants as a normal view? >>> >> We have only a dashboard sharing option as per now but not view sharing >> option. >> >> >>> In that case if a particular user gets a waning as you said at the time >>> of sharing, the user can create an anonymous view without those restricted >>> gadgets and share the dashboard with other tenants. Then, those tenant >>> users will be able to view the dashboards as explained in the above doc[1]. >>> Just an opinion. >>> >> Also anon view is for any non logged in users and we don't have to >> explicitly share it across tenants. >> >>> >>> Also, I think hiding gadgets won't work because it will introduce >>> unnecessary complications in re-arranging the template. If the restricted >>> gadget is in the middle of the template we can't keep a blank space in the >>> middle rather re-arrange it in a suitable way. >>> >> As I have explained in my previous reply, actual issue here is we are >> not aware of the existing roles in each tenant to hide a gadget based on >> gadget level permissions. >> >> Thanks, >> Tanya >> >>> >>> Regards, >>> Dilini >>> >>> On Thu, Jun 9, 2016 at 10:27 AM, Tanya Madurapperuma >>> wrote: >>> >>>> To add into what Megala has explained.. >>>> >>>> We decided the above approach due to below reasons. >>>> >>>>1. In the gadget listing page of the designer mode, we list only >>>>the intersection of the gadget that are authorized for the logged in >>>> user >>>>and restricted viewers of that particular view. So if we warn the >>>> dashboard >>>>creator saying "you have added a restricted gadget, if you share or >>>>planning share this dashboard across tenants, those gadget will be >>>> shown to >>>>the tenant users" at the time of adding a new gadget to the dashboard, >>>> he >>>>will be frustrated if he doesn't want to share this dashboard. So we >>>>skipped that option. >>>>2. We decided* only to warn* the user at the time of sharing the >>>>dashboard rather than hiding those gadgets in tenants view, because say >>>> a >>>>particular gadget is restricted only for Role1 in super tenant. There >>>> can >>>>be a role with the same name in another tenant which serves a different >>>>purpose. So blindly we can
Re: [Architecture] Access Level Model For WSO2 Dashboard Server
Hi Nisala, Shall we create global level permissions for gadget/layout upload and delete as they are very sensitive operations which can directly impact on dashboard creation? Note - Gadget/Layout upload and delete are new features that are going to be introduced with the new release. Thanks. Regards, Megala On Thu, Jun 9, 2016 at 4:32 PM, Nisala Nanayakkara wrote: > Hi Sinthuja, > > Thanks for the feedback. I will proceed with implementation. > > Thanks, > Nisala > > On Thu, Jun 9, 2016 at 4:26 PM, Sinthuja Ragendran > wrote: > >> Hi Nisala, >> >> On Thu, Jun 9, 2016 at 8:13 AM, Nisala Nanayakkara >> wrote: >> >>> Hi Sinthuja, >>> >>> This email is to clarify several issues regarding this feature. Up-to >>> now I have created a four internal roles as above. All these four roles are >>> assigned to the user who created the dashboard initially. If we want to >>> give specific permission to another user, we can assign appropriate role to >>> that user. As an example if we want to give access to the settings page to >>> a user, we can assign appropriate role to that user. >>> >>> But lets think that we have to give access to settings page of dashboard >>> X for all the users who have role A. Then how can we achieve that use-case >>> here ? >>> >> >> The operations of the dashboard will be assigned initially with the above >> mentioned roles, but you should be able include other roles also for that >> operation as same as we have now currently. And hence it's just adding >> roleA also along with internal/dashboardA/viewer role for example. >> >>> Are we going to the add UI configuration in settings page as for editor >>> and viewer ? >>> >> >> Yes, there should be separate options to assign and remove roles per >> operations. >> >>> Otherwise we have to go through all the users who have role A and assign >>> them with the dashboard X settings role using carbon management console. >>> >>> Another suggestion from me, Shall we create a single role called 'owner' >>> by merging settings role and delete role as manuranga mentioned ? >>> >> >> +1. >> >> Thanks, >> Sinthuja. >> >>> >>> Thanks, >>> Nisala >>> >>> On Tue, Jun 7, 2016 at 9:15 PM, Manuranga Perera wrote: >>> >>>> If we want to model with the permissions then we should be able to add >>>>> the permissions dynamically, but this is not possible with current carbon >>>>> - >>>>> 4.x. And as I have mentioned above, this cannot be included in the global >>>>> level as well, because having a settings or delete privileges for >>>>> dashboard >>>>> - X, doesn't mean you have the same privileges for dashboard - Y. And >>>>> hence >>>>> we thought of going with roles approach for this one as well. I agree, the >>>>> role names for settings and delete is bit odd, we need to come up with >>>>> proper names for those. :) >>>>> >>>> >>>> I think it is possible to dynamically create any permissions via the >>>> API even in C4 >>>> >>>> 2) Does "settings" make sense, because if you are an editor, anyway >>>>>> you'll have full access to the JSON, don't you? >>>>> >>>>> In settings you have the full privileges, ie, you can even remove the >>>>> user who initially created the dashboard, IMHO it provides the full >>>>> control >>>>> of the dashboard. Designer doesn't have such privileges, he/she can only >>>>> add/remove gadgets, pages etc which is related to designing the dashboard. >>>>> Therefore we need to have a different role to control the access of the >>>>> settings page. >>>> >>>> >>>> We may call this "Owners"? >>>> >>>> -- >>>> With regards, >>>> *Manu*ranga Perera. >>>> >>>> phone : 071 7 70 20 50 >>>> mail : m...@wso2.com >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Nisala Niroshana Nanayakkara,* >>> Software Engineer >>> Mobile:(+94)717600022 >>> WSO2 Inc., http://wso2.com/ >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Sinthuja Rajendran* >> Technical Lead >> WSO2, Inc.:http://wso2.com >> >> Blog: http://sinthu-rajan.blogspot.com/ >> Mobile: +94774273955 >> >> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Nisala Niroshana Nanayakkara,* > Software Engineer > Mobile:(+94)717600022 > WSO2 Inc., http://wso2.com/ > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Megala Uthayakumar Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [DS]Embeddable gadgets feature for Dashboard Server
Hi, Thanks for your suggestion. I will look into it. Thanks. Regards, Megala On Wed, Apr 27, 2016 at 12:16 PM, Sriskandarajah Suhothayan wrote: > Hi Megala > > I think its not necessary to communicate to DS if we are to do gadget to > gadget communication, but we have to provide a js library that the web page > developer need to embed in order to get the pub-sub working. > Via this library we can do the pub-sub locally within that page, and who > can communicate with whom information should also be passed to the lib such > that it knows how to pass messages across. > > Regards > Suho > > On Wed, Apr 27, 2016 at 10:10 AM, Megala Uthayakumar > wrote: > >> Hi, >> >> High Level view of gadget rendering is follow, >> >> Sorry for the inconvenience caused. >> >> Thanks. >> >> -- >> Megala Uthayakumar >> >> Software Engineer >> Mobile : 0779967122 >> > > > > -- > > *S. Suhothayan* > Technical Lead & Team Lead of WSO2 Complex Event Processor > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > -- Megala Uthayakumar Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [DS]Embeddable gadgets feature for Dashboard Server
Hi, High Level view of gadget rendering is follow, Sorry for the inconvenience caused. Thanks. -- Megala Uthayakumar Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [DS]Embeddable gadgets feature for Dashboard Server
Hi All, Following requirement is received from Analytics and IoT teams. Users - Dashboard designers Description - The users should be able to iframe the gadgets into another page or webapp. Further the user could define the pages, layout and render the gadgets, and there could be a pub-sub configuration between the gadgets. And it's required to iframe such designed gadgets into another app and provide the same level of functionality. Benefits - The platform capabilities are not bound within DS only, and could be used in other servers as well. Acceptance Criteria - 1. Should be able to iframe gadgets with it's settings into another page/webapp 2. Should be able to iframe the pub-sub gadgets of a page, into another page/webapp. In the current implementation of DS server, the gadget rendering happens as follow in a high level view, With this we cannot directly get the iframe url generated by shindig server to embed the gadget in the another location because that URL will not properly render all the functionalities related to that gadget when it is used outside the DS. So in order to solve this issue, we came up with following solution. We decided to give a separate URL for each gadgets using their gadget id and dashboard id and then we can use that URL to embed the gadgets in different web pages. But when we take the inter-gadget communication mechanism in DS server, it is done by pub-sub model. Wiring between publisher and subscriber happens through the parent container. But when we ship gadgets separately using unique URLs, we cannot achieve the inter-communication between gadgets through the above mentioned mechanism. So in order to solve this issue, we need to use the dashboard server as the mediation point between publisher and subscriber. In order to communicate with the server we need to use the web sockets. But if we use the web sockets, whenever a publisher publish events, it will be notified to all the subscribers since websockets cannot differentiate between different subscribers. Currently we are in the process of investigating other alternatives to satisfy these requirements. Any ideas and comments on this is highly appreciated. Thanks. Regards, Megala -- Megala Uthayakumar Software Engineer Mobile : 0779967122 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
