Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Gayan Gunawardana]

On Mon, Feb 12, 2018 at 12:11 PM, Isuranga Perera  wrote:

> Hi Gayan,
>
> Currently working on the configuration option. Sure I'll move changes to
> *identity-outbound-provisioning-scim*.
>
Thank you very much for the contribution.

>
> Best Regards
> Isuranga Perera
>
> On Mon, Feb 12, 2018 at 11:59 AM, Gayan Gunawardana 
> wrote:
>
>> Hi Isuranga,
>>
>> Could you be able to move *identity-outbound-**provisioning-scim2* to
>> *identity-outbound-provisioning-scim* by having configuration option for
>> SCIM 1.1 and 2.0 ?
>>
>> Thanks,
>> Gayan
>>
>> On Mon, Feb 5, 2018 at 10:48 AM, Isuranga Perera <
>> isurangamper...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> *@Gayan*
>>> yes, *identity-outbound-**provisioning-scim2* has the nearly same code
>>> as* identity-outbound-provisioning-scim. **identity-client-scim2 *simply
>>> encode and decode SCIM objects and validate some actions. As Malithi
>>> suggested we can use version as a connector configuration and instantiate
>>> the appropriate provisioning client. As an alternative, we can
>>> instantiate ScimClient [1] instead of ProvisioningClient since it provides
>>> almost all SCIM version specific functions related to object encoding and
>>> decoding. Anyway, if I'm not mistaken all of these changes are required
>>> only if we're going to use *identity-outbound-provisioning-scim* with
>>> SCIM client [2].
>>>
>>> *@Malithi*
>>> Will work on the SCIM response error code issue asap.
>>>
>>>
>>> [1] https://github.com/IsurangaPerera/identity-client-scim2/
>>> blob/ab5bdd6382ce4b055f99b65568c77289472c9c14/src/main/java/
>>> org/wso2/scim2/util/SCIMClient.java
>>> [2] https://github.com/wso2-extensions/identity-client-scim2/pull/1
>>>
>>>
>>> Best Regards
>>> Isuranga Perera
>>>
>>> On Sun, Feb 4, 2018 at 2:22 PM, Malithi Edirisinghe 
>>> wrote:
>>>
 Hi Gayan,

 +1 for the thought. Basically, it's always the CRUD operations being
 triggered for User and Group resources in the outbound provisioning flow
 and based on the version the respective client can initiate calls upon the
 protocol.
 So that's a matter of initializing the appropriate client based on the
 version that will be configured with respect to the protocol version used
 by the outbound party. That means version will be a connector configuration
 and the connector will instantiate the appropriate client upon the version
 with the application of factory pattern.

 *@Isuranga*,
 Thanks a lot for the contribution.
 Can we improve debug logs in the client to log respective requests
 calls and responses for outbound party.
 Also, looks like SCIM response errors are being swallowed in the client
 without passing them back to the connector [1]. In that case, the
 provisioning connector might not know if the request has been success or
 not and act accordingly.

 [1] https://github.com/wso2-extensions/identity-client-scim2/pul
 l/1/files#diff-5d09971e2f15b2c4858e2d49950f571cR75

 Thanks,
 Malithi.

 On Sat, Feb 3, 2018 at 6:01 PM, Gayan Gunawardana 
 wrote:

> Hi Isuranga,
>
> Thanks you very much for the contribution and definitely this will be
> a very valuable feature.
>
> I went through some of your PRs [1][2]. As I understood*
> identity-outbound-**provisioning-scim2* has nearly same code as*
> identity-outbound-provisioning-scim.* There is a good possibility for
> code duplication. Ideally protocol difference SCIM 1.1 and SCIM 2.0 should
> be very minimum to the provisioning connector level and protocol 
> difference
> should be handled from *ProvisioningClient*. I do not think existing
> SCIM 1.1 provisioning connector do much about SCIM specific logic rather 
> *org.wso2.carbon.identity.scim.common.impl.ProvisioningClient
> *handle all HTTP communication according to protocol. Is it possible
> to switch *ProvisioningClient* based on protocol (SCIM 1.1 and SCIM
> 2.0) ? @Darshana wdyt?
>
> I suppose in [2] swagger documentation doesn't have all error codes.
> For example user creation has only one error code (404) but there should 
> be
> many more like 409.
>
> Also could you be able to consider about unit test coverage ?
>
> Thanks again for your valuable contribution.
>
> [1] https://github.com/wso2-extensions/identity-outbound-provisi
> oning-scim2/pull/1
> [2] https://github.com/wso2-extensions/identity-client-scim2/pull/1
> [3] https://github.com/wso2-extensions/identity-outbound-provisi
> oning-scim/
>
> Thanks,
> Gayan
>
> On Mon, Nov 27, 2017 at 1:12 PM, Isuranga Perera <
> isurangamper...@gmail.com> wrote:
>
>> Hi,
>>
>> I've submitted PRs for identity-client-scim2 [1] and
>> identity-outbound-provisioning-scim2 [2]. There were some 

[Architecture] [IS] Personal information export UI option

[Ayesha Dissanayaka]

Hi all,

We have implemented Personal information export API as discussed in the
mail thread [1].

In order to enable this capability in the the user-portal UI, we are
planing to provide *"Download UserInfo"* option in the *"User Profile"*
gadget in the "Dashboard - https://localhost:9443/dashboard;


​
As shown above, there will be additional Button *"Download UserInfo"*  in
the User profile gadget. Once clicked it will call */api/identity/user/v1.0/me
(**Get the personal information of authenticated user) and download the
response into *"userInfo.json".

A sample *"userInfo.json"* is attached herewith.

[1] "Personal information export API"

-- 
*Ayesha Dissanayaka*
Senior Software Engineer,
WSO2, Inc : http://wso2.com

20, Palm grove Avenue, Colombo 3
E-Mail: aye...@wso2.com 


userInfo.json
Description: application/json
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [X509 Authenticator] Certificate Revocation Verification with CRL and OCSP

[Indunil Upeksha Rathnayake]

Adding Azeez

On Mon, Feb 12, 2018 at 10:28 AM, Maheshika Goonetilleke  wrote:

> hi Azeez
>
> Please confirm.
>
> On Mon, Feb 12, 2018 at 10:26 AM, Indunil Upeksha Rathnayake <
> indu...@wso2.com> wrote:
>
>> Hi Maheshika,
>>
>> Can you please create a new git repository with the name "
>> identity-x509-revocation" under wso2-extensions, for moving this feature
>> implementation.
>>
>> Thanks and Regards
>>
>> On Wed, Jan 17, 2018 at 11:20 AM, Indunil Upeksha Rathnayake <
>> indu...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> Please find the following considerations on proceeding with the CRL/OCSP
>>> certificate validation. Appreciate your ideas and comments on this.
>>>
>>> *Store root CA and intermediate CA certificates in registry*
>>>
>>>- As per the current implementation, trust stores which are having
>>>CA certificates that should be used for CRL and OCSP validation, can be
>>>configured file based as follows.
>>>
>>>
>>>
>>>http://wso2.org/project
>>>s/carbon/certificate-validation.xml
>>>">
>>>
>>>…….
>>>
>>>
>>>
>>>   *>>truststorePass="cacertspassword" type="JKS"/>*
>>>
>>>
>>>
>>>
>>>
>>>
>>>- In server start up and in tenant initial activation, all the
>>>certificates in the trust stores will added to the registry.
>>>
>>> Registry path : 
>>> *repository/security/certificate/certificate-authorities/>> Issuer DN>/*
>>>
>>> Normalized Issuer DN : UTF-8 URL encoded issuer DN while replacing the
>>> "%" with ":" in the URL encoded value, in order to support the Illegal
>>> characters for registry resource path (Check mail in [1]).
>>> Certificate Serial Num : Positive integer assigned by the CA to each
>>> certificate which is unique for each certificate issued by a given CA
>>> (i.e., the issuer name and serial number identify a unique certificate)
>>>
>>> Registry Content : *X509Certificate CA Certificate*
>>> Registry Properties :
>>> *crl - comma separated CRL URLs*
>>> *ocsp - comma separated OCSP URLs*
>>>
>>>- There can be certificates of Intermediate CAs and root CAs in the
>>>trust store (An intermediate CA is an entity that can sign certificates 
>>> on
>>>behalf of the root CA. The root CA signs the intermediate certificate,
>>>forming a chain of trust). All those intermediate  and root certificates
>>>will be added into the registry considering following scenarios.
>>>
>>>
>>>1. Intermediate CAs have their own CRL and OCSP URLs
>>>
>>> Revocation of certificate is not propagated across the CA tree. Each CA
>>> (root and intermediate) is responsible of the publication of the CRL
>>> containing the list of only the revoked certificates that were issued by
>>> that CA and OCSP response for only the certificates that were issued by
>>> that CA.
>>>
>>>2. Observer intermediate CA certificates in the chain
>>> of trust
>>> For full-chain CRL/OCSP validation as mention in below, need to have
>>> access to intermediate CA certificates in the chain of trust to retrieve
>>> the CRL and OCSP Urls
>>>
>>>
>>> *Need of CA and intermediate CA Certificates for CRL/OCSP validation*
>>>
>>>- CRL Validation :
>>>   - If the CA certificate available in the registry which issued
>>>   the client certificate, retrieve the CRL URLs from the CA cert. If 
>>> not use
>>>   the URLs in the client certificate.
>>>   - In order to validate intermediate CAs when Full-chain CRL/OCSP
>>>   validation enabled, CRL URls will be extracted from corresponding 
>>> root CA.
>>>
>>>
>>>- OCSP Validation :
>>>   - For OCSP validation, CA certificate which issued the client
>>>   certificate should be available in the registry. Otherwise consider 
>>> as a
>>>   unsuccessful validation.
>>>   - In order to validate intermediate CAs when Full-chain CRL/OCSP
>>>   validation enabled, OCSP URLs will be extracted from corresponding 
>>> root CA.
>>>
>>>
>>>
>>> *Configure Full-chain CRL/OCSP Validation *
>>>
>>> 
>>>
>>> http://wso2.org/project
>>> s/carbon/certificate-validation.xml">
>>>
>>> 
>>>
>>> >> displayName="CRLValidator" enable="false">
>>>
>>>   1
>>>
>>>*true*
>>>
>>>
>>> 
>>>
>>> >> displayName="OCSPValidator" enable="true">
>>>
>>>   2
>>>
>>>true
>>>
>>> 
>>>
>>> 
>>>
>>> 
>>>
>>>- *Full-chain CRL/OCSP validation disabled:* validate the client
>>>certificate with the CRL/OCSP URLs of the issuer CA
>>>
>>>
>>>- *Full-chain CRL/OCSP validation enabled*: validate with the
>>>CRL/OCSP of every intermediate certificate within the chain of trust for
>>>the client, except for the root CA certificate.
>>>
>>> Ex:  Root CA (root CA CRL) Cert ==> Intermediate CA Cert(inter CA CRL)
>>> ==> Client Cert
>>> The intermediate CA CRL is used to verify whether the client certificate
>>> is valid. The root CA CRL 

Re: [Architecture] [IAM] SCIM 2.0 Outbound Connector

[Dimuthu Leelarathne]

Hi Isuranga/Gayan and All,

WSO2 IS should be able to provision with both SCIM 1.1 and SCIM 2.0 at the
same time. There can be two systems - one supporting 1.1 and the other
supporting 2.0, and we need to provision users to both of them.

The above statement does *not* mean we need two separate outbound
connectors. It could mean we use one connector but that single connector
supports both of the protocols at the same time.

thanks,
Dimuthu


On Mon, Feb 12, 2018 at 3:26 PM, Gayan Gunawardana  wrote:

>
>
> On Mon, Feb 12, 2018 at 12:11 PM, Isuranga Perera <
> isurangamper...@gmail.com> wrote:
>
>> Hi Gayan,
>>
>> Currently working on the configuration option. Sure I'll move changes to
>> *identity-outbound-provisioning-scim*.
>>
> Thank you very much for the contribution.
>
>>
>> Best Regards
>> Isuranga Perera
>>
>> On Mon, Feb 12, 2018 at 11:59 AM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi Isuranga,
>>>
>>> Could you be able to move *identity-outbound-**provisioning-scim2* to
>>> *identity-outbound-provisioning-scim* by having configuration option
>>> for SCIM 1.1 and 2.0 ?
>>>
>>> Thanks,
>>> Gayan
>>>
>>> On Mon, Feb 5, 2018 at 10:48 AM, Isuranga Perera <
>>> isurangamper...@gmail.com> wrote:
>>>
 Hi,

 *@Gayan*
 yes, *identity-outbound-**provisioning-scim2* has the nearly same code
 as* identity-outbound-provisioning-scim. **identity-client-scim2 *simply
 encode and decode SCIM objects and validate some actions. As Malithi
 suggested we can use version as a connector configuration and instantiate
 the appropriate provisioning client. As an alternative, we can
 instantiate ScimClient [1] instead of ProvisioningClient since it provides
 almost all SCIM version specific functions related to object encoding and
 decoding. Anyway, if I'm not mistaken all of these changes are required
 only if we're going to use *identity-outbound-provisioning-scim* with
 SCIM client [2].

 *@Malithi*
 Will work on the SCIM response error code issue asap.


 [1] https://github.com/IsurangaPerera/identity-client-scim2/
 blob/ab5bdd6382ce4b055f99b65568c77289472c9c14/src/main/java/
 org/wso2/scim2/util/SCIMClient.java
 [2] https://github.com/wso2-extensions/identity-client-scim2/pull/1


 Best Regards
 Isuranga Perera

 On Sun, Feb 4, 2018 at 2:22 PM, Malithi Edirisinghe 
 wrote:

> Hi Gayan,
>
> +1 for the thought. Basically, it's always the CRUD operations being
> triggered for User and Group resources in the outbound provisioning flow
> and based on the version the respective client can initiate calls upon the
> protocol.
> So that's a matter of initializing the appropriate client based on the
> version that will be configured with respect to the protocol version used
> by the outbound party. That means version will be a connector 
> configuration
> and the connector will instantiate the appropriate client upon the version
> with the application of factory pattern.
>
> *@Isuranga*,
> Thanks a lot for the contribution.
> Can we improve debug logs in the client to log respective requests
> calls and responses for outbound party.
> Also, looks like SCIM response errors are being swallowed in the
> client without passing them back to the connector [1]. In that case, the
> provisioning connector might not know if the request has been success or
> not and act accordingly.
>
> [1] https://github.com/wso2-extensions/identity-client-scim2/pul
> l/1/files#diff-5d09971e2f15b2c4858e2d49950f571cR75
>
> Thanks,
> Malithi.
>
> On Sat, Feb 3, 2018 at 6:01 PM, Gayan Gunawardana 
> wrote:
>
>> Hi Isuranga,
>>
>> Thanks you very much for the contribution and definitely this will be
>> a very valuable feature.
>>
>> I went through some of your PRs [1][2]. As I understood*
>> identity-outbound-**provisioning-scim2* has nearly same code as*
>> identity-outbound-provisioning-scim.* There is a good possibility
>> for code duplication. Ideally protocol difference SCIM 1.1 and SCIM 2.0
>> should be very minimum to the provisioning connector level and protocol
>> difference should be handled from *ProvisioningClient*. I do not
>> think existing SCIM 1.1 provisioning connector do much about SCIM 
>> specific
>> logic rather 
>> *org.wso2.carbon.identity.scim.common.impl.ProvisioningClient
>> *handle all HTTP communication according to protocol. Is it possible
>> to switch *ProvisioningClient* based on protocol (SCIM 1.1 and SCIM
>> 2.0) ? @Darshana wdyt?
>>
>> I suppose in [2] swagger documentation doesn't have all error codes.
>> For example user creation has only one error code (404) but there should 
>> be
>> many more like 409.
>>
>> Also could 

Re: [Architecture] [IS] REST endpoint for Claim Management in IS

[Sanjeewa Malalgoda]

In that case please consider http status code 207[1] as simple resource
update actually handle multiple resource updates (which usually refer as
multi state update)

[1]https://httpstatuses.com/207

Thanks,
sanjeewa.

On Tue, Feb 13, 2018 at 12:00 PM, Chiran Wijesekara 
wrote:

> Hi Sanjeewa,
>
> Local claims are termed as attributes. That is *Attributes = Local claim
> Dialect* and further, the term attributes were used to lessen the
> confusion between those two.
> Thus, the dialect refers to the custom claim dialects other the Local
> Claim Dialect.When adding a dialect, providing claims is optional.
> And dialect contains external claims and just a mapping to local claims( 
> *under
> Attributes*).
> Hence, the claims that are supported by Identity Server is termed as
> attributes. Dialects(winch are custom definitions) contain external claims
> and mappings to ones under Attributes.
>
> Thanks.
>
> On Tue, Feb 13, 2018 at 11:50 AM, Chiran Wijesekara 
> wrote:
>
>> Hi Prasanna,
>> Appreciate your suggestion. However, It was done in such a way with the
>> RESTful design guidelines and usability in mind.
>> Thanks
>>
>> On Tue, Feb 13, 2018 at 11:28 AM, Sanjeewa Malalgoda 
>> wrote:
>>
>>> It looks like claims are attributes of dialect. In that case when user
>>> create/update dialect he should be able to create it with all claims he
>>> need.
>>> I hope that claims go to externalClaims tag in json. Can you explain how
>>> it works? Is user allowed to create dialect with all claims at once? If few
>>> claims added updated while rest failed how we should handle it.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>> On Tue, Feb 13, 2018 at 11:00 AM, Prasanna Dangalla 
>>> wrote:
>>>
 Hi Chiran,

 To mitigate the inconsistencies between SOAP end REST APIs parameters,
 is there a possibility to use same parameter names in SOAP and REST API's?.
 As an example in 'DeleteLocalClaim'  in SOAP claim ID is 'claimDialectURI'
 and in the given REST API solution its 'local-claim-id'.

 Thanks

 *Prasanna Dangalla*
 Senior Software Engineer, WSO2, Inc.; http://wso2.com/
 lean.enterprise.middleware


 *cell: +94 718 11 27 51*
 *twitter: @prasa77*

 On Mon, Feb 12, 2018 at 9:14 AM, Chiran Wijesekara 
 wrote:

> Hi Dakshika,
>
> Claim management via a REST API is not supported yet. Currently, it is
> supported with SOAP.
> Thank you for pointing out 409 and updated the .yml at appropriate
> places.
>
> Thank You.
>
> On Mon, Feb 12, 2018 at 8:49 AM, Dakshika Jayathilaka <
> daksh...@wso2.com> wrote:
>
>> Hi Chiran,
>>
>> Aren't we support for adding local claim via REST API?
>> Also, don't we need to add "409 conflicts" for the scenarios that
>> resource already exists?
>>
>> Regards,
>>
>> *Dakshika Jayathilaka*
>> PMC Member & Committer of Apache Stratos
>> Associate Technical Lead
>> WSO2, Inc.
>> lean.enterprise.middleware
>> 0771100911 <077%20110%200911>
>>
>> On Sat, Feb 10, 2018 at 9:34 AM, Chiran Wijesekara 
>> wrote:
>>
>>> Hi Isura,
>>>
>>> Thank you very much for your feedback.
>>> I had gone through your comments and did the changes accordingly.
>>> Please find the updated Swagger .yaml [1] attached below.
>>> [1] https://app.swaggerhub.com/apis/chirankavinda123/claim_manag
>>> ement_service_endpoint/1.0.0
>>>
>>> Thank You.
>>>
>>> On Sat, Feb 10, 2018 at 1:19 AM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Chiran,

 Please find the inline comments.

 1)


 POST/dialects/{id}
 
 Add New Claim Dialect.
 The context for the posting a dialect should be like bellow.


 POST/dialects
 
 Add New Claim Dialect.
 Also, the request body should contain, dialect URI (name) with the
 external claims array.


 2)



 DELETE/dialect/{id}
 
 Delete Claim Dialect
 Delete claim dialect should be like bellow

 DELETE/dialects/{id}
 
 Delete Claim Dialect


 3)


 

Re: [Architecture] [IS] REST endpoint for Claim Management in IS

[Chiran Wijesekara]

Hi Prasanna,
Appreciate your suggestion. However, It was done in such a way with the
RESTful design guidelines and usability in mind.
Thanks

On Tue, Feb 13, 2018 at 11:28 AM, Sanjeewa Malalgoda 
wrote:

> It looks like claims are attributes of dialect. In that case when user
> create/update dialect he should be able to create it with all claims he
> need.
> I hope that claims go to externalClaims tag in json. Can you explain how
> it works? Is user allowed to create dialect with all claims at once? If few
> claims added updated while rest failed how we should handle it.
>
> Thanks,
> sanjeewa.
>
>
> On Tue, Feb 13, 2018 at 11:00 AM, Prasanna Dangalla 
> wrote:
>
>> Hi Chiran,
>>
>> To mitigate the inconsistencies between SOAP end REST APIs parameters, is
>> there a possibility to use same parameter names in SOAP and REST API's?. As
>> an example in 'DeleteLocalClaim'  in SOAP claim ID is 'claimDialectURI' and
>> in the given REST API solution its 'local-claim-id'.
>>
>> Thanks
>>
>> *Prasanna Dangalla*
>> Senior Software Engineer, WSO2, Inc.; http://wso2.com/
>> lean.enterprise.middleware
>>
>>
>> *cell: +94 718 11 27 51*
>> *twitter: @prasa77*
>>
>> On Mon, Feb 12, 2018 at 9:14 AM, Chiran Wijesekara 
>> wrote:
>>
>>> Hi Dakshika,
>>>
>>> Claim management via a REST API is not supported yet. Currently, it is
>>> supported with SOAP.
>>> Thank you for pointing out 409 and updated the .yml at appropriate
>>> places.
>>>
>>> Thank You.
>>>
>>> On Mon, Feb 12, 2018 at 8:49 AM, Dakshika Jayathilaka >> > wrote:
>>>
 Hi Chiran,

 Aren't we support for adding local claim via REST API?
 Also, don't we need to add "409 conflicts" for the scenarios that
 resource already exists?

 Regards,

 *Dakshika Jayathilaka*
 PMC Member & Committer of Apache Stratos
 Associate Technical Lead
 WSO2, Inc.
 lean.enterprise.middleware
 0771100911 <077%20110%200911>

 On Sat, Feb 10, 2018 at 9:34 AM, Chiran Wijesekara 
 wrote:

> Hi Isura,
>
> Thank you very much for your feedback.
> I had gone through your comments and did the changes accordingly.
> Please find the updated Swagger .yaml [1] attached below.
> [1] https://app.swaggerhub.com/apis/chirankavinda123/claim_manag
> ement_service_endpoint/1.0.0
>
> Thank You.
>
> On Sat, Feb 10, 2018 at 1:19 AM, Isura Karunaratne 
> wrote:
>
>> Hi Chiran,
>>
>> Please find the inline comments.
>>
>> 1)
>>
>>
>> POST/dialects/{id}
>> 
>> Add New Claim Dialect.
>> The context for the posting a dialect should be like bellow.
>>
>>
>> POST/dialects
>> 
>> Add New Claim Dialect.
>> Also, the request body should contain, dialect URI (name) with the
>> external claims array.
>>
>>
>> 2)
>>
>>
>>
>> DELETE/dialect/{id}
>> 
>> Delete Claim Dialect
>> Delete claim dialect should be like bellow
>>
>> DELETE/dialects/{id}
>> 
>> Delete Claim Dialect
>>
>>
>> 3)
>>
>>
>> GET/dialect
>> 
>> Get Available Claim Dialects
>>
>> Get Available Claim Dialects should be as follows.
>>
>>
>> GET/dialects
>> 
>> Get Available Claim Dialects
>>
>>
>> 4)
>>
>>
>> PUT/dialect
>> 
>> Update existing claim dialect.
>>
>> Update existing claim dialect should be as follows,
>>
>> PUT/dialects/{id}
>> 
>> Update existing claim dialect.
>>
>>
>>
>> 5)
>>
>>
>> PUT/dialects/{id}/claims
>> 
>> update an external claim.
>> DELETE/dialects/{id}/claims
>> 

Re: [Architecture] [IS] REST endpoint for Claim Management in IS

[Chiran Wijesekara]

Hi Sanjeewa,

Local claims are termed as attributes. That is *Attributes = Local claim
Dialect* and further, the term attributes were used to lessen the confusion
between those two.
Thus, the dialect refers to the custom claim dialects other the Local Claim
Dialect.When adding a dialect, providing claims is optional.
And dialect contains external claims and just a mapping to local claims( *under
Attributes*).
Hence, the claims that are supported by Identity Server is termed as
attributes. Dialects(winch are custom definitions) contain external claims
and mappings to ones under Attributes.

Thanks.

On Tue, Feb 13, 2018 at 11:50 AM, Chiran Wijesekara 
wrote:

> Hi Prasanna,
> Appreciate your suggestion. However, It was done in such a way with the
> RESTful design guidelines and usability in mind.
> Thanks
>
> On Tue, Feb 13, 2018 at 11:28 AM, Sanjeewa Malalgoda 
> wrote:
>
>> It looks like claims are attributes of dialect. In that case when user
>> create/update dialect he should be able to create it with all claims he
>> need.
>> I hope that claims go to externalClaims tag in json. Can you explain how
>> it works? Is user allowed to create dialect with all claims at once? If few
>> claims added updated while rest failed how we should handle it.
>>
>> Thanks,
>> sanjeewa.
>>
>>
>> On Tue, Feb 13, 2018 at 11:00 AM, Prasanna Dangalla 
>> wrote:
>>
>>> Hi Chiran,
>>>
>>> To mitigate the inconsistencies between SOAP end REST APIs parameters,
>>> is there a possibility to use same parameter names in SOAP and REST API's?.
>>> As an example in 'DeleteLocalClaim'  in SOAP claim ID is 'claimDialectURI'
>>> and in the given REST API solution its 'local-claim-id'.
>>>
>>> Thanks
>>>
>>> *Prasanna Dangalla*
>>> Senior Software Engineer, WSO2, Inc.; http://wso2.com/
>>> lean.enterprise.middleware
>>>
>>>
>>> *cell: +94 718 11 27 51*
>>> *twitter: @prasa77*
>>>
>>> On Mon, Feb 12, 2018 at 9:14 AM, Chiran Wijesekara 
>>> wrote:
>>>
 Hi Dakshika,

 Claim management via a REST API is not supported yet. Currently, it is
 supported with SOAP.
 Thank you for pointing out 409 and updated the .yml at appropriate
 places.

 Thank You.

 On Mon, Feb 12, 2018 at 8:49 AM, Dakshika Jayathilaka <
 daksh...@wso2.com> wrote:

> Hi Chiran,
>
> Aren't we support for adding local claim via REST API?
> Also, don't we need to add "409 conflicts" for the scenarios that
> resource already exists?
>
> Regards,
>
> *Dakshika Jayathilaka*
> PMC Member & Committer of Apache Stratos
> Associate Technical Lead
> WSO2, Inc.
> lean.enterprise.middleware
> 0771100911 <077%20110%200911>
>
> On Sat, Feb 10, 2018 at 9:34 AM, Chiran Wijesekara 
> wrote:
>
>> Hi Isura,
>>
>> Thank you very much for your feedback.
>> I had gone through your comments and did the changes accordingly.
>> Please find the updated Swagger .yaml [1] attached below.
>> [1] https://app.swaggerhub.com/apis/chirankavinda123/claim_manag
>> ement_service_endpoint/1.0.0
>>
>> Thank You.
>>
>> On Sat, Feb 10, 2018 at 1:19 AM, Isura Karunaratne 
>> wrote:
>>
>>> Hi Chiran,
>>>
>>> Please find the inline comments.
>>>
>>> 1)
>>>
>>>
>>> POST/dialects/{id}
>>> 
>>> Add New Claim Dialect.
>>> The context for the posting a dialect should be like bellow.
>>>
>>>
>>> POST/dialects
>>> 
>>> Add New Claim Dialect.
>>> Also, the request body should contain, dialect URI (name) with the
>>> external claims array.
>>>
>>>
>>> 2)
>>>
>>>
>>>
>>> DELETE/dialect/{id}
>>> 
>>> Delete Claim Dialect
>>> Delete claim dialect should be like bellow
>>>
>>> DELETE/dialects/{id}
>>> 
>>> Delete Claim Dialect
>>>
>>>
>>> 3)
>>>
>>>
>>> GET/dialect
>>> 
>>> Get Available Claim Dialects
>>>
>>> Get Available Claim Dialects should be as follows.
>>>
>>>
>>> GET/dialects
>>> 
>>> Get Available Claim Dialects

Re: [Architecture] [IS] REST endpoint for Claim Management in IS

[Prasanna Dangalla]

Hi Chiran,

To mitigate the inconsistencies between SOAP end REST APIs parameters, is
there a possibility to use same parameter names in SOAP and REST API's?. As
an example in 'DeleteLocalClaim'  in SOAP claim ID is 'claimDialectURI' and
in the given REST API solution its 'local-claim-id'.

Thanks

*Prasanna Dangalla*
Senior Software Engineer, WSO2, Inc.; http://wso2.com/
lean.enterprise.middleware


*cell: +94 718 11 27 51*
*twitter: @prasa77*

On Mon, Feb 12, 2018 at 9:14 AM, Chiran Wijesekara  wrote:

> Hi Dakshika,
>
> Claim management via a REST API is not supported yet. Currently, it is
> supported with SOAP.
> Thank you for pointing out 409 and updated the .yml at appropriate places.
>
> Thank You.
>
> On Mon, Feb 12, 2018 at 8:49 AM, Dakshika Jayathilaka 
> wrote:
>
>> Hi Chiran,
>>
>> Aren't we support for adding local claim via REST API?
>> Also, don't we need to add "409 conflicts" for the scenarios that
>> resource already exists?
>>
>> Regards,
>>
>> *Dakshika Jayathilaka*
>> PMC Member & Committer of Apache Stratos
>> Associate Technical Lead
>> WSO2, Inc.
>> lean.enterprise.middleware
>> 0771100911
>>
>> On Sat, Feb 10, 2018 at 9:34 AM, Chiran Wijesekara 
>> wrote:
>>
>>> Hi Isura,
>>>
>>> Thank you very much for your feedback.
>>> I had gone through your comments and did the changes accordingly. Please
>>> find the updated Swagger .yaml [1] attached below.
>>> [1] https://app.swaggerhub.com/apis/chirankavinda123/claim_manag
>>> ement_service_endpoint/1.0.0
>>>
>>> Thank You.
>>>
>>> On Sat, Feb 10, 2018 at 1:19 AM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Chiran,

 Please find the inline comments.

 1)


 POST/dialects/{id}
 
 Add New Claim Dialect.
 The context for the posting a dialect should be like bellow.


 POST/dialects
 
 Add New Claim Dialect.
 Also, the request body should contain, dialect URI (name) with the
 external claims array.


 2)



 DELETE/dialect/{id}
 
 Delete Claim Dialect
 Delete claim dialect should be like bellow

 DELETE/dialects/{id}
 
 Delete Claim Dialect


 3)


 GET/dialect
 
 Get Available Claim Dialects

 Get Available Claim Dialects should be as follows.


 GET/dialects
 
 Get Available Claim Dialects


 4)


 PUT/dialect
 
 Update existing claim dialect.

 Update existing claim dialect should be as follows,

 PUT/dialects/{id}
 
 Update existing claim dialect.



 5)


 PUT/dialects/{id}/claims
 
 update an external claim.
 DELETE/dialects/{id}/claims
 
 Delete external Claim

 Update and delete External claims should be as follows


 PUT/dialects/{dialect-id}/claims/{claim-id}
 
 update an external claim.
 DELETE/dialects/{dialect-id}/claims/{claim-id}
 
 Delete external Claim







 PUT/attributes
 
 Update a Local Claim.

 Update a Local Claim should be as follows


 PUT/attributes/{local-claim-id}
 

[Architecture] Updated invitation: [IS] Architecture Review for SAML SSO HTTP... @ Tue Feb 13, 2018 1pm - 2pm (IST) (architecture@wso2.org)

[indunil]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20180213T073000Z
DTEND:20180213T083000Z
DTSTAMP:20180213T054040Z
ORGANIZER;CN=indu...@wso2.com:mailto:indu...@wso2.com
UID:7qnie84b1epvq6ogvi45hrp...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Johann Nallathamby;X-NUM-GUESTS=0:mailto:joh...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=indu...@wso2.com;X-NUM-GUESTS=0:mailto:indu...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Ruwan Abeykoon;X-NUM-GUESTS=0:mailto:ruw...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Darshana Gunawardana;X-NUM-GUESTS=0:mailto:darsh...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Hasintha Indrajee;X-NUM-GUESTS=0:mailto:hasin...@wso2.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
 UE;CN="LK 4th Floor Meeting Room - Sinharaja Ext:1005470";X-NUM-GUESTS=0:ma
 ilto:wso2.com_2d313435363638382d323...@resource.calendar.google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Prabath Siriwardena;X-NUM-GUESTS=0:mailto:prab...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Pulasthi Mahawithana;X-NUM-GUESTS=0:mailto:pulast...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Ishara Karunarathna;X-NUM-GUESTS=0:mailto:isha...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Sagara Gunathunga;X-NUM-GUESTS=0:mailto:sag...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Thanuja Jayasinghe;X-NUM-GUESTS=0:mailto:than...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Malithi Edirisinghe;X-NUM-GUESTS=0:mailto:malit...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=architecture@wso2.org;X-NUM-GUESTS=0:mailto:architecture@wso2.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Isura Karunaratne;X-NUM-GUESTS=0:mailto:is...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=je...@wso2.com;X-NUM-GUESTS=0:mailto:je...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Tharinda Basnayake;X-NUM-GUESTS=0:mailto:tharin...@wso2.com
CREATED:20180212T045953Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nThis event has a video call.\nJoin: https://meet.google.com/zsc-fkai-
 ovh\n\nView your event at https://www.google.com/calendar/event?action=VIEW
 =N3FuaWU4NGIxZXB2cTZvZ3ZpNDVocnBscGQgYXJjaGl0ZWN0dXJlQHdzbzIub3Jn=M
 TYjaW5kdW5pbEB3c28yLmNvbTUyMzUyNmU5OWFmNmIxYmE1NDEzYjU3NGI1ZmQyZDA2ZmRlNWIy
 ODg=Asia/Colombo=en.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180213T054040Z
LOCATION:LK 4th Floor Meeting Room - Sinharaja Ext:1005470
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:[Architecture] [IS] Architecture Review for SAML SSO HTTP Artifact 
 Binding
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Updated invitation: [IS] Architecture Review for SAML SSO HTTP... @ Tue Feb 13, 2018 2pm - 3pm (IST) (architecture@wso2.org)

[indunil]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20180213T083000Z
DTEND:20180213T093000Z
DTSTAMP:20180213T054436Z
ORGANIZER;CN=indu...@wso2.com:mailto:indu...@wso2.com
UID:7qnie84b1epvq6ogvi45hrp...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Johann Nallathamby;X-NUM-GUESTS=0:mailto:joh...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=indu...@wso2.com;X-NUM-GUESTS=0:mailto:indu...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Ruwan Abeykoon;X-NUM-GUESTS=0:mailto:ruw...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Darshana Gunawardana;X-NUM-GUESTS=0:mailto:darsh...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Hasintha Indrajee;X-NUM-GUESTS=0:mailto:hasin...@wso2.com
ATTENDEE;CUTYPE=RESOURCE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TR
 UE;CN="LK 4th Floor Meeting Room - Sinharaja Ext:1005470";X-NUM-GUESTS=0:ma
 ilto:wso2.com_2d313435363638382d323...@resource.calendar.google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Prabath Siriwardena;X-NUM-GUESTS=0:mailto:prab...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Pulasthi Mahawithana;X-NUM-GUESTS=0:mailto:pulast...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Ishara Karunarathna;X-NUM-GUESTS=0:mailto:isha...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Sagara Gunathunga;X-NUM-GUESTS=0:mailto:sag...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Thanuja Jayasinghe;X-NUM-GUESTS=0:mailto:than...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Malithi Edirisinghe;X-NUM-GUESTS=0:mailto:malit...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=architecture@wso2.org;X-NUM-GUESTS=0:mailto:architecture@wso2.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Isura Karunaratne;X-NUM-GUESTS=0:mailto:is...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=je...@wso2.com;X-NUM-GUESTS=0:mailto:je...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Tharinda Basnayake;X-NUM-GUESTS=0:mailto:tharin...@wso2.com
CREATED:20180212T045953Z
DESCRIPTION:-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~
 :~:~:~:~:~:~:~:~::~:~::-\nPlease do not edit this section of the descriptio
 n.\n\nThis event has a video call.\nJoin: https://meet.google.com/zsc-fkai-
 ovh\n\nView your event at https://www.google.com/calendar/event?action=VIEW
 =N3FuaWU4NGIxZXB2cTZvZ3ZpNDVocnBscGQgYXJjaGl0ZWN0dXJlQHdzbzIub3Jn=M
 TYjaW5kdW5pbEB3c28yLmNvbTUyMzUyNmU5OWFmNmIxYmE1NDEzYjU3NGI1ZmQyZDA2ZmRlNWIy
 ODg=Asia/Colombo=en.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:
 ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20180213T054436Z
LOCATION:LK 4th Floor Meeting Room - Sinharaja Ext:1005470
SEQUENCE:2
STATUS:CONFIRMED
SUMMARY:[Architecture] [IS] Architecture Review for SAML SSO HTTP Artifact 
 Binding
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] REST endpoint for Claim Management in IS

[Sanjeewa Malalgoda]

It looks like claims are attributes of dialect. In that case when user
create/update dialect he should be able to create it with all claims he
need.
I hope that claims go to externalClaims tag in json. Can you explain how it
works? Is user allowed to create dialect with all claims at once? If few
claims added updated while rest failed how we should handle it.

Thanks,
sanjeewa.


On Tue, Feb 13, 2018 at 11:00 AM, Prasanna Dangalla 
wrote:

> Hi Chiran,
>
> To mitigate the inconsistencies between SOAP end REST APIs parameters, is
> there a possibility to use same parameter names in SOAP and REST API's?. As
> an example in 'DeleteLocalClaim'  in SOAP claim ID is 'claimDialectURI' and
> in the given REST API solution its 'local-claim-id'.
>
> Thanks
>
> *Prasanna Dangalla*
> Senior Software Engineer, WSO2, Inc.; http://wso2.com/
> lean.enterprise.middleware
>
>
> *cell: +94 718 11 27 51*
> *twitter: @prasa77*
>
> On Mon, Feb 12, 2018 at 9:14 AM, Chiran Wijesekara 
> wrote:
>
>> Hi Dakshika,
>>
>> Claim management via a REST API is not supported yet. Currently, it is
>> supported with SOAP.
>> Thank you for pointing out 409 and updated the .yml at appropriate
>> places.
>>
>> Thank You.
>>
>> On Mon, Feb 12, 2018 at 8:49 AM, Dakshika Jayathilaka 
>> wrote:
>>
>>> Hi Chiran,
>>>
>>> Aren't we support for adding local claim via REST API?
>>> Also, don't we need to add "409 conflicts" for the scenarios that
>>> resource already exists?
>>>
>>> Regards,
>>>
>>> *Dakshika Jayathilaka*
>>> PMC Member & Committer of Apache Stratos
>>> Associate Technical Lead
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>> 0771100911 <077%20110%200911>
>>>
>>> On Sat, Feb 10, 2018 at 9:34 AM, Chiran Wijesekara 
>>> wrote:
>>>
 Hi Isura,

 Thank you very much for your feedback.
 I had gone through your comments and did the changes accordingly.
 Please find the updated Swagger .yaml [1] attached below.
 [1] https://app.swaggerhub.com/apis/chirankavinda123/claim_manag
 ement_service_endpoint/1.0.0

 Thank You.

 On Sat, Feb 10, 2018 at 1:19 AM, Isura Karunaratne 
 wrote:

> Hi Chiran,
>
> Please find the inline comments.
>
> 1)
>
>
> POST/dialects/{id}
> 
> Add New Claim Dialect.
> The context for the posting a dialect should be like bellow.
>
>
> POST/dialects
> 
> Add New Claim Dialect.
> Also, the request body should contain, dialect URI (name) with the
> external claims array.
>
>
> 2)
>
>
>
> DELETE/dialect/{id}
> 
> Delete Claim Dialect
> Delete claim dialect should be like bellow
>
> DELETE/dialects/{id}
> 
> Delete Claim Dialect
>
>
> 3)
>
>
> GET/dialect
> 
> Get Available Claim Dialects
>
> Get Available Claim Dialects should be as follows.
>
>
> GET/dialects
> 
> Get Available Claim Dialects
>
>
> 4)
>
>
> PUT/dialect
> 
> Update existing claim dialect.
>
> Update existing claim dialect should be as follows,
>
> PUT/dialects/{id}
> 
> Update existing claim dialect.
>
>
>
> 5)
>
>
> PUT/dialects/{id}/claims
> 
> update an external claim.
> DELETE/dialects/{id}/claims
> 
> Delete external Claim
>
> Update and delete External claims should be as follows
>
>
> PUT/dialects/{dialect-id}/claims/{claim-id}
>