Re: [Architecture] [GDPR] API Manager 3.0.0 GDPR Support

[Sanjeewa Malalgoda]

On Fri, Feb 9, 2018 at 12:27 AM, Chamila De Alwis  wrote:

> Hi Sanjeewa,
>
> Because it's not clear from this thread,
>
> 1. How are we planning to remove user specific data from analytics where
> log entries and other identification are submitted and processed, on demand?
>
Log entries will not contain real user name or scimID. Log will contain
only pseudo name and once we remove mapping we are done with that.

> 2. Are we showing any relationship between an ID and the pseudoname in any
> place? Would it violate the "right to be forgotten" part of GDPR if any
> analysis can map an ID (even if it's a random but constant UUID directly
> mapped to user data) after the fact?
>
No we do not show that any place. Also we do not expose service to get that
mapping. Its completely administrative task and admin need to figure out
that. As of now we need to remove data base entry which contain mapping.

>
> IMO GDPR compliance should be an exposable API where external systems can
> take control, and even turn off by default (as mody organizations seem to
> voluntarily opt out of it even after the deadline [1])
>
As we understood GDPR is more about internal data usage. Whenever we deal
with external parties we will use ID or real name.
And it looks like GDPR should enable by default and it should cover "Data
protection by design and by default". Please see below.

"
The controller shall implement appropriate technical and organisational
measures for ensuring that, by default, only personal data which are
necessary for each specific purpose of the processing are processed. That
obligation applies to the amount of personal data collected, the extent of
their processing, the period of their storage and their accessibility. In
particular, such measures shall ensure that by default personal data are
not made accessible without the individual’s intervention to an indefinite
number of natural persons.
"

[1]https://gdpr-info.eu/art-25-gdpr/

Thanks,
sanjeewa.

> [1] - page 10 - https://go.forrester.com/wp-content/uploads/Forrester-
> 2018-Predictions.pdf
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Associate Technical Lead | WSO2
> +94 77 220 7163 <077%20220%207163>
> Blog: https://medium.com/@chamilad
>
>
>
> On Thu, Feb 8, 2018 at 1:50 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi All,
>> We were able to implement above suggested solution for API Manager 3.0.0
>> and test user flows successfully. Also we did integrations with identity
>> server 5.4.0 as authenticate service to verify external system
>> communication part. If user resides outside product domain(in tested
>> scenarion IS 5.4.0) we have to delete user from identity server side and
>> remove internal mapping. We do not have any plan to expose this
>> functionality as a web service to outside due to security concerns. APIM
>> components will be able to communicate with this through java API and get
>> mappings.
>>
>> Do you have any suggestion to implement mechanism to mapping removal?
>> Should we expose API or java method to do that? Or let database admin to
>> remove mapping from database?
>> Appreciate suggestions.
>>
>> Thanks,
>> sanjeewa.
>>
>> On Wed, Feb 7, 2018 at 3:06 PM, Ishara Karunarathna 
>> wrote:
>>
>>> Hi Sanjeewa,
>>>
>>> On Tue, Feb 6, 2018 at 12:33 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>


 On Mon, Feb 5, 2018 at 11:29 PM, Ishara Karunarathna 
 wrote:

> HI Sanjeewa,
>
> Pseudonym user ID (User ID) is not only limited to GDPR requirements
> but its really useful supporting features like changing userName, In C4 we
> do some workaround for this.
>
> I think this proposed approach is much similar to the pseudonym user
> ID implementation we did to support GDPR features in C4 based products.
> Where we have users in the system and later we introduce a mapping to 
> those
> existing users. (Jayanga and Ruwan can add more on this).
>
> But IMO, I think in the new implementation we can provide first-class
> support for this. So we can create a user context with userID and
> displayName (Username), all the places we use the user ID, but when we
> display the users we can show the displayName or (username)
>
 Yes we had discussion about subject and it was decided to use user
 pseudo name in all places of the implementation. But whenever we need to
 show user logged in name we will call user info or some other service and
 get display name. That part will be handle from UI app and back end run
 time do not need to worry about it. I think this implementation align with
 your suggestion. Please let us know if you have any suggestion to above
 flow.

>>> If this userID to display name conversion is not a frequest task this
>>> seems good
>>>
>>> Thanks,
>>> Ishara
>>>

 Thanks,
 sanjeewa.

>

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Hasintha Indrajee]

Can we also validate these certificates using CRLs and OSCP endpoints
provided in certificate ?. Also better if this validation can be made
optional and can be governed through a configuration. This configuration
will just be a handler property.

*@Indunil : *Do we have this feature bundled in product (Certificate
validation using OSCP and CRL) ?

On Fri, Feb 9, 2018 at 12:20 PM, Sathya Bandara  wrote:

> Hi all,
>
> Mutual TLS is a widely used, secure, authentication technique in
> enterprise environments to ensure the authenticity of the clients to server
> and vice versa. It facilitates authentication via certificates followed by
> the establishment of an encrypted channel between the parties.
>
> The OAuth 2.0 Authorization Framework allows the use of additional client
> authentication mechanisms. One such is the mechanism of client
> authentication utilizing mutual TLS certificate-based authentication [1].
> We can add this support for WSO2 Identity Server by providing an additional
> OAuth client authenticator. In order to utilize TLS for OAuth client
> authentication, the TLS connection between the client and the authorization
> server must have been established with mutual X.509 certificate
> authentication (i.e. the Client Certificate and Certificate Verify messages
> are sent during the TLS Handshake).
>
>
> The specification defines two ways of binding a certificate to a client as
> two distinct client authentication methods [2].
> 1. PKI Mutual TLS OAuth Client Authentication Method
>
> Uses a subject distinguished name (DN) and validated certificate chain to 
> identify the client. The client is successfully authenticated if the subject 
> information in the certificate matches the expected DN configured or 
> registered for that
> particular client.
>
> 2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Method
> Mutual
>
> support client authentication using self-signed certificates.  As
> pre-requisite, the client registers an X.509 certificate or a trusted
> source for its X.509 certificates (such as the "jwks_uri"). The client is
> successfully authenticated, if the subject public key info of the
> certificate matches the subject public key info of one of the certificates
> configured or registered for that particular client.
>
> In both approaches, TLS is utilized to validate the client's possession of
> the private key corresponding to the public key presented within the
> certificate in the respective TLS handshake during authentication.
>
> We will follow the approach #2 since it prevents the necessity to validate
> the certificate chain in contrast to the PKI method.
>
>
> Also since the client cert authentication happens as part of the mutual
> TLS handshake, it will happen at the web container level. Hence if the
> authentication is successful, client's public certificate will be available
> as a request attribute at the CXF servlet. Hence the Mutual TLS Client
> Authenticator can be engaged by inferring the existence of the client cert
> as a request attribute.
>
> As we currently have the capability to upload Service Provider specific
> public certificates, clients can register their public certificates during
> service provider configuration. Within the authenticate method of the
> MutualTLSClientAuthenticator, we can compare the registered certificate's
> public key against the public key of the certificate presented in the TLS
> handshake. If these two matches we can successfully authenticate the
> client.
>
> For all requests to the authorization server utilizing mutual TLS client
> authentication, the client MUST include the "client_id" parameter as
> described in OAuth 2.0 specification [3]. With the "client_id" parameter we
> can easily obtain the client's registered certificate for authenticating
> the client.
>
> Highly appreciate your thoughts and suggestions.
>
> [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07
> [2] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1
> [3] https://tools.ietf.org/html/rfc6749#section-2.2
>
> Thanks,
> Sathya
>
> --
> Sathya Bandara
> Software Engineer
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

Hi all,

Mutual TLS is a widely used, secure, authentication technique in enterprise
environments to ensure the authenticity of the clients to server and vice
versa. It facilitates authentication via certificates followed by the
establishment of an encrypted channel between the parties.

The OAuth 2.0 Authorization Framework allows the use of additional client
authentication mechanisms. One such is the mechanism of client
authentication utilizing mutual TLS certificate-based authentication [1].
We can add this support for WSO2 Identity Server by providing an additional
OAuth client authenticator. In order to utilize TLS for OAuth client
authentication, the TLS connection between the client and the authorization
server must have been established with mutual X.509 certificate
authentication (i.e. the Client Certificate and Certificate Verify messages
are sent during the TLS Handshake).


The specification defines two ways of binding a certificate to a client as
two distinct client authentication methods [2].
1. PKI Mutual TLS OAuth Client Authentication Method

Uses a subject distinguished name (DN) and validated certificate chain
to identify the client. The client is successfully authenticated if
the subject information in the certificate matches the expected DN
configured or registered for that
particular client.

2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Method
Mutual

support client authentication using self-signed certificates.  As
pre-requisite, the client registers an X.509 certificate or a trusted
source for its X.509 certificates (such as the "jwks_uri"). The client is
successfully authenticated, if the subject public key info of the
certificate matches the subject public key info of one of the certificates
configured or registered for that particular client.

In both approaches, TLS is utilized to validate the client's possession of
the private key corresponding to the public key presented within the
certificate in the respective TLS handshake during authentication.

We will follow the approach #2 since it prevents the necessity to validate
the certificate chain in contrast to the PKI method.


Also since the client cert authentication happens as part of the mutual TLS
handshake, it will happen at the web container level. Hence if the
authentication is successful, client's public certificate will be available
as a request attribute at the CXF servlet. Hence the Mutual TLS Client
Authenticator can be engaged by inferring the existence of the client cert
as a request attribute.

As we currently have the capability to upload Service Provider specific
public certificates, clients can register their public certificates during
service provider configuration. Within the authenticate method of the
MutualTLSClientAuthenticator, we can compare the registered certificate's
public key against the public key of the certificate presented in the TLS
handshake. If these two matches we can successfully authenticate the
client.

For all requests to the authorization server utilizing mutual TLS client
authentication, the client MUST include the "client_id" parameter as
described in OAuth 2.0 specification [3]. With the "client_id" parameter we
can easily obtain the client's registered certificate for authenticating
the client.

Highly appreciate your thoughts and suggestions.

[1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07
[2] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1
[3] https://tools.ietf.org/html/rfc6749#section-2.2

Thanks,
Sathya

-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Personal information export API

[Maduranga Siriwardena]

Now the problem is how these claims are returned. If you configure security
questions for a user, when the user information is exported, below is the
data sent with the current implementation.

"basic":{
  "http://wso2.org/claims/userid":"a42b7c0a-ae21-46c9-bb78-3bfeb8e7625c;
,
  "http://wso2.org/claims/username":"admin;,
  "http://wso2.org/claims/created":"2018-02-08T14:34:06Z;,
  "http://wso2.org/claims/role":"Internal/everyone,admin;,
  *"http://wso2.org/claims/challengeQuestion2
"*:
"Model of your first car ?!jhcb4EciCCjfWfAd5tfR24vpYzE93ahv6REJQ8uZFW0=",
  "http://wso2.org/claims/fullname":"admin;,
  "http://wso2.org/claims/modified":"2018-02-08T14:34:06Z;,
  *"http://wso2.org/claims/challengeQuestion1
"*:
"City where you were born ?!YPWTFQ5dt0xLWKAkEQoQy/AEakfIYIBlwaWKgOO23YI=",
  "http://wso2.org/claims/emailaddress":"ad...@wso2.com;,
  "http://wso2.org/claims/lastname":"admin;,
  *"http://wso2.org/claims/challengeQuestionUris
"*:"
http://wso2.org/claims/challengeQuestion1!http://wso2.org/claims/challengeQuestion2
",
  "http://wso2.org/claims/givenname":"admin;
   }

Note the claims marked in red color above. Though the value of these claims
makes sense inside the identity server, they might not make sense once they
are exported.

And in the same time, these claims are a separate category of claims. So if
we can divide them to separate categories, it would make much sense in my
opinion. What would be the best way to achieve this?


On Fri, Feb 9, 2018 at 11:18 AM, Ruwan Abeykoon  wrote:

> Hi Maduranga,
> I consider anything related to user as PI.
> So security questions and answers also falls into this. We need to send
> these even if we keep them hashed (the hash value)
>
> Cheers,
> Ruwan
>
> On Fri, Feb 9, 2018 at 11:12 AM, Maduranga Siriwardena  > wrote:
>
>> Do we need to add security related information of the user also to the
>> response?
>>
>> For example the security questions configured by the user
>>
>> Thanks,
>>
>> On Thu, Feb 8, 2018 at 12:02 PM, Maduranga Siriwardena <
>> madura...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> Based on the discussions had offline we did few changes to the api. We
>>> have come up with 3 endpoints.
>>>
>>> /api/identity/user/v1.0/me
>>> Get the personal information of authenticated user.
>>>
>>> /api/identity/user/v1.0/pi-info/{userId}
>>> Get the personal information of the user with the given id. Users with
>>> "administrative" privileges can invoke this api. We need to decide what
>>> level authorization needed for this operation.
>>>
>>> /api/identity/user/v1.0/pi-info?username=
>>> Get the user ids and usernames of the given username pattern. This might
>>> not be implemented at the moment.
>>>
>>> Thanks,
>>> Maduranga.
>>>
>>> On Wed, Jan 24, 2018 at 8:33 PM, Isura Karunaratne 
>>> wrote:
>>>


 On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena <
 madura...@wso2.com> wrote:

> If the user is in secondary userstore, fully qualified username
> contains "/" character. But seems to be we can't send url encoded "/"
> characters (%2F) in path parameters. We are evaluating possible solutions
> for this. If this is not an option, we are planing to base 64 encode the
> username and then url encode it.
>
> We already has a web application with name api#identity#user [1]. So
> we are planing to use the same repository for this code also.
>

 Yes. We can use the same application.

>
> [1] https://github.com/wso2-extensions/identity-governance/t
> ree/v1.0.38/components/org.wso2.carbon.identity.user.endpoint
>
> Thanks,
>
> On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena <
> madura...@wso2.com> wrote:
>
>>
>>
>> On Tue, Jan 23, 2018 at 10:35 AM, Omindu Rathnaweera > > wrote:
>>
>>>
>>> Hi Maduranga,
>>>
>>> On Tue, Jan 23, 2018 at 10:23 AM, Maduranga Siriwardena <
>>> madura...@wso2.com> wrote:
>>>
 Hi all,

 Web app name we have come up for this endpoint
 is api#identity#user#v1.0 and the path for the endpoint is
 /pi/users/{userId}. So the whole endpoint would be

- for super tenant,

 /api/identity/user/v1.0/pi/users/{userId}


- for tenant,

 /t/{tenant-domain}/api/identity/user/v1.0/pi/users/{userId}


 IMO  we can use following format,

 / t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}


 Thanks
 Isura.

>
 Our initial plan was to use the ID used in Pseudonyms for username
 feature [1]. But as the ID used by Pseudonyms for username feature is 
 not

Re: [Architecture] [Dev] Personal information export API

[Ruwan Abeykoon]

Hi Maduranga,
I consider anything related to user as PI.
So security questions and answers also falls into this. We need to send
these even if we keep them hashed (the hash value)

Cheers,
Ruwan

On Fri, Feb 9, 2018 at 11:12 AM, Maduranga Siriwardena 
wrote:

> Do we need to add security related information of the user also to the
> response?
>
> For example the security questions configured by the user
>
> Thanks,
>
> On Thu, Feb 8, 2018 at 12:02 PM, Maduranga Siriwardena  > wrote:
>
>> Hi all,
>>
>> Based on the discussions had offline we did few changes to the api. We
>> have come up with 3 endpoints.
>>
>> /api/identity/user/v1.0/me
>> Get the personal information of authenticated user.
>>
>> /api/identity/user/v1.0/pi-info/{userId}
>> Get the personal information of the user with the given id. Users with
>> "administrative" privileges can invoke this api. We need to decide what
>> level authorization needed for this operation.
>>
>> /api/identity/user/v1.0/pi-info?username=
>> Get the user ids and usernames of the given username pattern. This might
>> not be implemented at the moment.
>>
>> Thanks,
>> Maduranga.
>>
>> On Wed, Jan 24, 2018 at 8:33 PM, Isura Karunaratne 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena <
>>> madura...@wso2.com> wrote:
>>>
 If the user is in secondary userstore, fully qualified username
 contains "/" character. But seems to be we can't send url encoded "/"
 characters (%2F) in path parameters. We are evaluating possible solutions
 for this. If this is not an option, we are planing to base 64 encode the
 username and then url encode it.

 We already has a web application with name api#identity#user [1]. So
 we are planing to use the same repository for this code also.

>>>
>>> Yes. We can use the same application.
>>>

 [1] https://github.com/wso2-extensions/identity-governance/t
 ree/v1.0.38/components/org.wso2.carbon.identity.user.endpoint

 Thanks,

 On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena <
 madura...@wso2.com> wrote:

>
>
> On Tue, Jan 23, 2018 at 10:35 AM, Omindu Rathnaweera 
> wrote:
>
>>
>> Hi Maduranga,
>>
>> On Tue, Jan 23, 2018 at 10:23 AM, Maduranga Siriwardena <
>> madura...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> Web app name we have come up for this endpoint
>>> is api#identity#user#v1.0 and the path for the endpoint is
>>> /pi/users/{userId}. So the whole endpoint would be
>>>
>>>- for super tenant,
>>>
>>> /api/identity/user/v1.0/pi/users/{userId}
>>>
>>>
>>>- for tenant,
>>>
>>> /t/{tenant-domain}/api/identity/user/v1.0/pi/users/{userId}
>>>
>>>
>>> IMO  we can use following format,
>>>
>>> / t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}
>>>
>>>
>>> Thanks
>>> Isura.
>>>

>>> Our initial plan was to use the ID used in Pseudonyms for username
>>> feature [1]. But as the ID used by Pseudonyms for username feature is 
>>> not
>>> available to outside, we cannot use it here. Next option available to 
>>> us is
>>> the ID used in SCIM. But as it is not mandatory to have SCIM ID in 
>>> system
>>> (when SCIM is disabled), we cannot use this option also.
>>>
>>> Because of above reasons, we are planing to use base 64 encoded
>>> fully qualified username as the userId in the above request.
>>>
>>
>> Would like to know the rationale behind base64 encoding the username.
>> Also if it has to be b64 encoded for some reason then it should be base64
>> URL encoded I believe.
>>
>
> Yes this should be url encoding.
>
>>
>>
>>>
>>> Do you have any suggestions?
>>>
>>> [1] [Architecture] GDPR - Pseudonyms For Username
>>>
>>> Thanks,
>>>
>>> On Mon, Jan 22, 2018 at 5:52 PM, Hasintha Indrajee <
>>> hasin...@wso2.com> wrote:
>>>
 In a federated user scenario, we neither have user information nor
 email address of the user in a case if the user is not JIT. Hence we 
 won't
 be able to share consents with user in an offline method. But still for
 federated users we need to maintain consents which we give out to SPs. 
 We
 can process this offline and store somewhere (consent info ready for
 download). The way we share will depend. eg - For the users who have 
 emails
 we can send them through an email (as a download link). If not we can 
 share
 those information through another medium (eg - user profile at a later
 login)

 On Mon, Jan 22, 2018 at 5:40 PM, Ruwan Abeykoon 
 wrote:

> Hi Hasintha,
> We do not need to export anything we do not keep in our databases.

Re: [Architecture] [Dev] Personal information export API

[Maduranga Siriwardena]

Do we need to add security related information of the user also to the
response?

For example the security questions configured by the user

Thanks,

On Thu, Feb 8, 2018 at 12:02 PM, Maduranga Siriwardena 
wrote:

> Hi all,
>
> Based on the discussions had offline we did few changes to the api. We
> have come up with 3 endpoints.
>
> /api/identity/user/v1.0/me
> Get the personal information of authenticated user.
>
> /api/identity/user/v1.0/pi-info/{userId}
> Get the personal information of the user with the given id. Users with
> "administrative" privileges can invoke this api. We need to decide what
> level authorization needed for this operation.
>
> /api/identity/user/v1.0/pi-info?username=
> Get the user ids and usernames of the given username pattern. This might
> not be implemented at the moment.
>
> Thanks,
> Maduranga.
>
> On Wed, Jan 24, 2018 at 8:33 PM, Isura Karunaratne  wrote:
>
>>
>>
>> On Wed, Jan 24, 2018 at 2:20 PM, Maduranga Siriwardena <
>> madura...@wso2.com> wrote:
>>
>>> If the user is in secondary userstore, fully qualified username contains
>>> "/" character. But seems to be we can't send url encoded "/" characters
>>> (%2F) in path parameters. We are evaluating possible solutions for this. If
>>> this is not an option, we are planing to base 64 encode the username and
>>> then url encode it.
>>>
>>> We already has a web application with name api#identity#user [1]. So we
>>> are planing to use the same repository for this code also.
>>>
>>
>> Yes. We can use the same application.
>>
>>>
>>> [1] https://github.com/wso2-extensions/identity-governance/t
>>> ree/v1.0.38/components/org.wso2.carbon.identity.user.endpoint
>>>
>>> Thanks,
>>>
>>> On Tue, Jan 23, 2018 at 10:40 AM, Maduranga Siriwardena <
>>> madura...@wso2.com> wrote:
>>>


 On Tue, Jan 23, 2018 at 10:35 AM, Omindu Rathnaweera 
 wrote:

>
> Hi Maduranga,
>
> On Tue, Jan 23, 2018 at 10:23 AM, Maduranga Siriwardena <
> madura...@wso2.com> wrote:
>
>> Hi all,
>>
>> Web app name we have come up for this endpoint
>> is api#identity#user#v1.0 and the path for the endpoint is
>> /pi/users/{userId}. So the whole endpoint would be
>>
>>- for super tenant,
>>
>> /api/identity/user/v1.0/pi/users/{userId}
>>
>>
>>- for tenant,
>>
>> /t/{tenant-domain}/api/identity/user/v1.0/pi/users/{userId}
>>
>>
>> IMO  we can use following format,
>>
>> / t/{tenant-domain}/api/identity/user/v1.0/pi-info/{id}
>>
>>
>> Thanks
>> Isura.
>>
>>>
>> Our initial plan was to use the ID used in Pseudonyms for username
>> feature [1]. But as the ID used by Pseudonyms for username feature is not
>> available to outside, we cannot use it here. Next option available to us 
>> is
>> the ID used in SCIM. But as it is not mandatory to have SCIM ID in system
>> (when SCIM is disabled), we cannot use this option also.
>>
>> Because of above reasons, we are planing to use base 64 encoded fully
>> qualified username as the userId in the above request.
>>
>
> Would like to know the rationale behind base64 encoding the username.
> Also if it has to be b64 encoded for some reason then it should be base64
> URL encoded I believe.
>

 Yes this should be url encoding.

>
>
>>
>> Do you have any suggestions?
>>
>> [1] [Architecture] GDPR - Pseudonyms For Username
>>
>> Thanks,
>>
>> On Mon, Jan 22, 2018 at 5:52 PM, Hasintha Indrajee > > wrote:
>>
>>> In a federated user scenario, we neither have user information nor
>>> email address of the user in a case if the user is not JIT. Hence we 
>>> won't
>>> be able to share consents with user in an offline method. But still for
>>> federated users we need to maintain consents which we give out to SPs. 
>>> We
>>> can process this offline and store somewhere (consent info ready for
>>> download). The way we share will depend. eg - For the users who have 
>>> emails
>>> we can send them through an email (as a download link). If not we can 
>>> share
>>> those information through another medium (eg - user profile at a later
>>> login)
>>>
>>> On Mon, Jan 22, 2018 at 5:40 PM, Ruwan Abeykoon 
>>> wrote:
>>>
 Hi Hasintha,
 We do not need to export anything we do not keep in our databases.
 Could you please explain further if we need to do anything extra
 for Federated case.

 Cheers,
 Ruwan

 On Mon, Jan 22, 2018 at 5:33 PM, Hasintha Indrajee <
 hasin...@wso2.com> wrote:

> Just a quick question. How are we going to cater consents for
> federated user ? Having consent from 3rd party IDP to IS will not be 
> enough
> AFAIU. If we 

[Architecture] WSO2 Identity Server 5.5.0-M4 Released!

[Sathya Bandara]

*WSO2 Identity and Access Management team is pleased to announce the
release of Identity Server 5.5.0 M4!DownloadYou can download WSO2 Identity
Server 5.5.0 M4 from here
.How
to run 1. Extract the downloaded zip file. 2. Go to the bin directory in
the extracted folder. 3. Run the wso2server.sh file if you are on a
Linux/Mac OS or run the wso2server.bat file if you are on a Windows OS. 4.
Optionally, if you need to start the OSGi console with the server, use the
-DosgiConsole property when starting the server.What's new in WSO2 Identity
Server 5.5.0 M4*


   -

   Consent Management API
    to
   manage user consents for collecting and sharing user's personal information
   .
   -

   Request Object Support for OIDC
   

   providing ability to send authentication request parameters in a
   self-contained JWT instead of plain request parameters complying with GDPR
   and PSD2 standards.
   -

   Store service provider cert in DB instead of the keystore
   

   facilitating the upload of Service Provider specific public certificates.
   -

   UI Based JWT configuration support
   

   for configuring service provider specific JWT audiences via SP Oauth config
   UI.





*A list of all the new features and bug fixes shipped with this release can
be found here 
Online
documentation is available at
https://docs.wso2.com/display/IS550/WSO2+Identity+Server+Documentation
.*
















*Known IssuesAll the open issues pertaining to WSO2 Identity Server are
reported at the following location: - IS Runtime
How You Can ContributeMailing
ListsJoin our mailing list and correspond with the developers directly.
Developer list: d...@wso2.org  | Subscribe | Mail Archive
 User forum: StackOverflow
Reporting IssuesWe
encourage you to report issues, improvements, documentation faults, and
feature requests regarding WSO2 Identity Server through WSO2 Identity
Server GIT Issues .For more
information about WSO2 Identity Server, please see
https://wso2.com/identity-and-access-management
 or visit the WSO2 Oxygen
Tank  developer portal for additional resources.~
The WSO2 Identity and Access Management Team ~*
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Support for encrypted ID tokens in OIDC

[Vihanga Liyanage]

[- Engineering, Strategy]
[+ Architecture, Dev]

Thanks,
Vihanga

On Fri, Feb 9, 2018 at 8:56 AM, Vihanga Liyanage  wrote:

> Hi Farasath,
>
> For the above two points IMO it would be better to provide an option at
>> Service Provider OAuth/OIDC configuration. This will be similar to what we
>> have done for SAML.
>>
>
> That is the initial idea came to me as well. But shouldn't the clients
> have a choice of deciding that as well? May be through a request parameter.
> To use either JWS or JWE, the client have to support them right?
>
>>
>> On a separate note, any specific reason why we are discussing this in
>> strategy and not in Dev and architecture mailing lists?
>>
>> I feel that we need to discuss this feature in architecture mailing list
>> to get the input from community.
>>
>
> No such specific reason at all. On the previous project I did, the mail
> was asked to sent to engineering and strategy. So I followed the same
> protocol. I'll change that now.
>
>>
>>
>>>
>>> Thanks,
>>> Vihanga.
>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] 
>>>
>>>
>>> 
>>>  Virus-free.
>>> www.avast.com
>>> 
>>> <#m_-5520087002137875506_m_-4545884336410447238_m_682166417964237_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "WSO2 Engineering Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to engineering-group+unsubscr...@wso2.com.
>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>>
>>
>>
>> --
>> Farasath Ahamed
>> Senior Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>>
>>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>



-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.4.1 Update1 Released !!!

[Nilasini Thirunavukkarasu]

The WSO2 Identity and Access Management team is pleased to announce the
release of WSO2 Identity Server 5.4.1 Update1.
You can build the distribution from the source tag,

Runtime: https://github.com/wso2/product-is/releases/tag/v5.4.1-update1

follow the steps given below.

*Building from the source*

   1. Install Java8 or above
   2. Install Apache Maven 3.x.x(https://maven.apache.org/download.cgi#)
   3. Get the source,
  - For the Runtime: Get a clone from https://github.com/wso2/p
  roduct-is.git and checkout to v5.4.1-update1 tag or you can directly
  download the source for the tag from https://github.com/wso2/
  product-is/releases/tag/v5.4.1-update1
  1
   4. Run the one of the below maven commands from product-is directory,
  - *mvn** clean install* (To build the binary and source distributions
  with the tests)
  - *mvn** clean install -Dmaven.test.skip=true* (To build the binary
  and source distributions, without running any of the
unit/integration tests)
   5. You can find the wso2is-5.4.1-update1.zip binary distribution in
   product-is/modules/distribution/target directory.

What's new in WSO2 Identity Server 5.4.1 Update1

New Features & Bug Fixes: A list of new features and bug fixes shipped with
this release can be found here
 and here
.
Download

You can download WSO2 Identity Server 5.4.1 Update1 here

.
Contribute to WSO2 Identity ServerMailing Lists

Join our mailing lists and correspond with the developers directly. We also
encourage you to take part in discussions related to the product in the
architecture mailing list. If you have any questions regarding the product
you can use our StackOverflow forum to raise them as well.

   -

   Developer List: d...@wso2.org
   -

   Architecture List: architecture@wso2.org
   -

   User Forum: StackOverflow
   

Reporting Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server GIT
Issues .


~ The WSO2 Identity and Access Management Team ~


-- 
Nilasini Thirunavukkarasu
Software Engineer - WSO2

Email : nilas...@wso2.com
Mobile : +94775241823 <+94%2077%20524%201823>
Web : http://wso2.com/



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

Re: [Architecture] [GDPR] API Manager 3.0.0 GDPR Support

[Chamila De Alwis]

Hi Sanjeewa,

Because it's not clear from this thread,

1. How are we planning to remove user specific data from analytics where
log entries and other identification are submitted and processed, on demand?
2. Are we showing any relationship between an ID and the pseudoname in any
place? Would it violate the "right to be forgotten" part of GDPR if any
analysis can map an ID (even if it's a random but constant UUID directly
mapped to user data) after the fact?

IMO GDPR compliance should be an exposable API where external systems can
take control, and even turn off by default (as mody organizations seem to
voluntarily opt out of it even after the deadline [1])

[1] - page 10 -
https://go.forrester.com/wp-content/uploads/Forrester-2018-Predictions.pdf


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Associate Technical Lead | WSO2
+94 77 220 7163
Blog: https://medium.com/@chamilad



On Thu, Feb 8, 2018 at 1:50 PM, Sanjeewa Malalgoda 
wrote:

> Hi All,
> We were able to implement above suggested solution for API Manager 3.0.0
> and test user flows successfully. Also we did integrations with identity
> server 5.4.0 as authenticate service to verify external system
> communication part. If user resides outside product domain(in tested
> scenarion IS 5.4.0) we have to delete user from identity server side and
> remove internal mapping. We do not have any plan to expose this
> functionality as a web service to outside due to security concerns. APIM
> components will be able to communicate with this through java API and get
> mappings.
>
> Do you have any suggestion to implement mechanism to mapping removal?
> Should we expose API or java method to do that? Or let database admin to
> remove mapping from database?
> Appreciate suggestions.
>
> Thanks,
> sanjeewa.
>
> On Wed, Feb 7, 2018 at 3:06 PM, Ishara Karunarathna 
> wrote:
>
>> Hi Sanjeewa,
>>
>> On Tue, Feb 6, 2018 at 12:33 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>>
>>>
>>> On Mon, Feb 5, 2018 at 11:29 PM, Ishara Karunarathna 
>>> wrote:
>>>
 HI Sanjeewa,

 Pseudonym user ID (User ID) is not only limited to GDPR requirements
 but its really useful supporting features like changing userName, In C4 we
 do some workaround for this.

 I think this proposed approach is much similar to the pseudonym user
 ID implementation we did to support GDPR features in C4 based products.
 Where we have users in the system and later we introduce a mapping to those
 existing users. (Jayanga and Ruwan can add more on this).

 But IMO, I think in the new implementation we can provide first-class
 support for this. So we can create a user context with userID and
 displayName (Username), all the places we use the user ID, but when we
 display the users we can show the displayName or (username)

>>> Yes we had discussion about subject and it was decided to use user
>>> pseudo name in all places of the implementation. But whenever we need to
>>> show user logged in name we will call user info or some other service and
>>> get display name. That part will be handle from UI app and back end run
>>> time do not need to worry about it. I think this implementation align with
>>> your suggestion. Please let us know if you have any suggestion to above
>>> flow.
>>>
>> If this userID to display name conversion is not a frequest task this
>> seems good
>>
>> Thanks,
>> Ishara
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>

 Thanks,
 Ishara



 On Fri, Feb 2, 2018 at 4:52 PM, Nuwan Dias  wrote:

> Hi all,
>
> When this is done up to some extent let's have a code review. I'm
> still struggling to understand the difference between user_id and pseudo
> name. And wondering whether we actually need a user_id concept if we
> implement something based on a pseudo name or vice versa.
>
> Just to be clear on the GDPR expectations, processing data with
> usernames in memory has absolutely no problem in terms of GDPR compliance.
> The only problem occurs when/if we persist a username somewhere. So as 
> long
> as we don't log a username and don't write to a DB or file, we're good.
> Since developers have access to the username at the development time, they
> can still log it or write it to a DB or file anyway.
>
> @Shani, GDPR compliance rules apply over other rules. It's not
> intended to override other organizational rules. So if a particular
> organization has a policy to retain user data for 6 months and the user 
> has
> consented to that, the user only has the "right to be forgotten" after the
> 6 months has passed. Until then the organization has the right to hold on
> to that data.
>
> Thanks,
> NuwanD.
>
> On Fri, Feb 2, 2018 at 11:11 AM, Sanjeewa Malalgoda  > wrote:
>

[Architecture] WSO2 API Manager 3.0.0-M17 Released!

[Pubudu Gunatilaka]

The WSO2 API Manager team is pleased to announce the release of API Manager
3.0.0-M17. It's now available to download.

Distribution

   - https://github.com/wso2/product-apim/releases/download/v3.0.0
   -m17/wso2apim-3.0.0-m17.zip
   

   - https://github.com/wso2/product-apim/releases/download/v3.0.0
   -m17/wso2apim-gateway-3.0.0-m17.zip
   


Documentation

   - https://docs.wso2.com/display/AM300/

Following list contains all the features, improvements and bug fixes
available with this milestone.
New Features

   - 
*https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=label%3A3.0.0+milestone%3A3.0.0-m17+is%3Aclosed+label%3A%22Type%2FNew+Feature%22+
   
*
   - 
*https://github.com/wso2/carbon-auth/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+closed%3A2018-02-01..2018-02-08+label%3A%22Type%2FNew+Feature%22+
   
*

Bug Fixes

   - 
*https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+milestone%3A3.0.0-m17+label%3AType%2FBug+
   
*

Improvements

   - 
*https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aclosed+milestone%3A3.0.0-m17+label%3AType%2FImprovement+
   
*

List of Open Issues

   - https://github.com/wso2/product-apim/issues?q=is%3Aopen+is%3
   Aissue+label%3A3.0.0+label%3AType%2FBug
   


How To Contribute

Your feedback is most welcome!
Mailing Lists

   - Join our mailing list and correspond with the developers directly.

Developer List : d...@wso2.org | Subscribe | Mail Archive


   - User Forum : StackOverflow
   

Reporting Issues

We encourage you to report issues, improvements and feature requests
regarding WSO2 API Manager through WSO2 API Manager GIT Issues
.

~ WSO2 API Manager Team ~
-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Senior Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] WSO2 Vagrant Resources Released!

[Ching Tien Shi]

Hi all,

Sorry for the noise. Followings are the correct URL links.
*Released Artifacts:*

   -

   WSO2 Enterprise Integrator - https://github.com/wso2/vagrant-ei
   -

   WSO2 API Manager - https://github.com/wso2/vagrant-apim
   -

   WSO2 Identity Server - https://github.com/wso2/vagrant-is


Issues:

   -

   WSO2 Enterprise Integrator - https://github.com/wso2/vagrant-ei/issues
   -

   WSO2 API Manager - https://github.com/wso2/vagrant-apim/issues
   -

   WSO2 Identity Server - https://github.com/wso2/vagrant-is/issues

Thanks and regards,

Ching Shi
Software Engineer
WSO2

Email: ch...@wso2.com
Mobile: +94770186272
Web: http://wso2.com
[image: http://wso2.com/signature] 


On Thu, Feb 8, 2018 at 7:09 PM, Ching Tien Shi  wrote:

> WSO2 Installation Experience team is pleased to announce the release of
> WSO2 Vagrant resources.
>
> Released Artifacts:
>
>-
>
>WSO2 Enterprise Integrator - https://github.com/wso2/vagrant-ei
>
>-
>
>WSO2 API Manager - https://github.com/wso2/
>vagrant
>-apim
>
>-
>
>WSO2 Identity Server - https://github.com/wso2/
>vagrant
>-is
>
>
>
> Issues:
>
>-
>
>WSO2 Enterprise Integrator - https://github.com/wso2/
>vagrant
>-ei/issues
>
>-
>
>WSO2 API Manager - https://github.com/wso2/
>vagrant
>-apim/issues
>
>-
>
>WSO2 Identity Server - https://github.com/wso2/
>vagrant
>-is/issues
>
>
>
> How You Can Contribute
>
> Join our mailing list and correspond with the developers directly.
>
>-
>
>Developer List: d...@wso2.org
>-
>
>User List: u...@wso2.org
>
>
> Reporting Issues
>
> We encourage you to report issues and documentation faults regarding WSO2
> Vagrant resources through respective repositories by creating issues.
>
> Thank you!
>
> WSO2 Installation Experience Team
>
>
> Ching Shi
> Software Engineer
> WSO2
>
> Email: ch...@wso2.com
> Mobile: +94770186272 <+94%2077%20018%206272>
> Web: http://wso2.com
> [image: http://wso2.com/signature] 
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] WSO2 Vagrant Resources Released!

[Ching Tien Shi]

Hi all,

The links are as follows. Sorry for the inconvenience caused.

Released Artifacts:

   -

   WSO2 Enterprise Integrator - https://github.com/wso2/vagrant-ei
   -

   WSO2 API Manager - https://github.com/wso2/
   vagrant
   -apim
   
   -

   WSO2 Identity Server - https://github.com/wso2/
   vagrant
   -is
   


Issues:

   -

   WSO2 Enterprise Integrator - https://github.com/wso2/
   vagrant
   -ei/issues
   
   -

   WSO2 API Manager - https://github.com/wso2/
   vagrant
   -apim/issues
   
   -

   WSO2 Identity Server - https://github.com/wso2/
   vagrant
   -is/issues
   



Ching Shi
Software Engineer
WSO2

Email: ch...@wso2.com
Mobile: +94770186272
Web: http://wso2.com
[image: http://wso2.com/signature] 


On Thu, Feb 8, 2018 at 7:46 PM, Ching Tien Shi  wrote:

> WSO2 Installation Experience team is pleased to announce the release of
> WSO2 Vagrant resources.
>
> Released Artifacts:
>
>-
>
>WSO2 Enterprise Integrator - https://github.com/wso2/vagrant-ei
>
>-
>
>WSO2 API Manager - https://github.com/wso2/
>vagrant
>-apim
>
>-
>
>WSO2 Identity Server - https://github.com/wso2/
>vagrant
>-is
>
>
>
> Issues:
>
>-
>
>WSO2 Enterprise Integrator - https://github.com/wso2/
>vagrant
>-ei/issues
>
>-
>
>WSO2 API Manager - https://github.com/wso2/
>vagrant
>-apim/issues
>
>-
>
>WSO2 Identity Server - https://github.com/wso2/
>vagrant
>-is/issues
>
>
>
> How You Can Contribute
>
> Join our mailing list and correspond with the developers directly.
>
>-
>
>Developer List: d...@wso2.org
>-
>
>User List: u...@wso2.org
>
>
> Reporting Issues
>
> We encourage you to report issues and documentation faults regarding WSO2
> Vagrant resources through respective repositories by creating issues.
>
> Thank you!
>
> WSO2 Installation Experience Team
>
>
> Ching Shi
> Software Engineer
> WSO2
>
> Email: ch...@wso2.com
> Mobile: +94770186272 <+94%2077%20018%206272>
> Web: http://wso2.com
> [image: http://wso2.com/signature] 
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Vagrant Resources Released!

[Ching Tien Shi]

WSO2 Installation Experience team is pleased to announce the release of
WSO2 Vagrant resources.

Released Artifacts:

   -

   WSO2 Enterprise Integrator - https://github.com/wso2/vagrant-ei
   
   -

   WSO2 API Manager - https://github.com/wso2/
   vagrant
   -apim
   
   -

   WSO2 Identity Server - https://github.com/wso2/
   vagrant
   -is
   


Issues:

   -

   WSO2 Enterprise Integrator - https://github.com/wso2/
   vagrant
   -ei/issues
   
   -

   WSO2 API Manager - https://github.com/wso2/
   vagrant
   -apim/issues
   
   -

   WSO2 Identity Server - https://github.com/wso2/
   vagrant
   -is/issues
   


How You Can Contribute

Join our mailing list and correspond with the developers directly.

   -

   Developer List: d...@wso2.org
   -

   User List: u...@wso2.org


Reporting Issues

We encourage you to report issues and documentation faults regarding WSO2
Vagrant resources through respective repositories by creating issues.

Thank you!

WSO2 Installation Experience Team


Ching Shi
Software Engineer
WSO2

Email: ch...@wso2.com
Mobile: +94770186272
Web: http://wso2.com
[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Announce] WSO2 Enterprise Integrator 6.1.1-update20 Released !

[Malaka Gangananda]

Hi All,

The WSO2 Integration team is pleased to announce the release of Enterprise
Integrator 6.1.1-update20.

It is available for download from here

.

*Tasks/Bug Fixes and Improvements*

   - https://github.com/wso2/product-ei/milestone/28?closed=1
   - https://wso2.org/jira/issues/?filter=14517

*​​List of Open Issues*

   - https://wso2.org/jira/issues/?filter=13994
   - https://github.com/wso2/product-ei/issues?q=is%3Aopen+is%3Aissue

*Documentation*

   - https://docs.wso2.com/display/EI611/WSO2+Enterprise+
   Integrator+Documentation

*How To Contribute*

Your feedback is most welcome!

*Reporting Issues​*

We encourage you to report issues, improvements and feature requests
regarding WSO2 Integrator through WSO2 EI GIT Issues
.

*Mailing Lists*

Join our mailing lists and correspond with the developers directly.

Developer List : d...@wso2.org | Subscribe | Mail Archive

WSO2 Architecture List: architecture@wso2.org

User Forum : StackOverflow 

Thanks,

-- 
Malaka.
-- 
Malaka Gangananda - Software Engineer | WSO2
Email : mala...@wso2.com
Mobile : +94713564340
Web : http://wso2.com
  
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Clearly defining what operations users can perform on a shared application in APIM

[Uvindra Dias Jayasinha]

Yes we can safely prevent shared users from regenerating access tokens of
Apps that they are not owners of. This ideally shouldnt be an issue since
Apps should have provision to regenerate a token if required.

On 8 February 2018 at 14:23, Sanjeewa Malalgoda  wrote:

> Can shared users generate keys for the application? After first time if
> one user regenerate application access key then it will effect others as we
> revoke and generate application token.
> I think regenerate option and application access token visibility also
> should remove for above shared users. I think generate token with resource
> owner grant by non app owner may cause issues.
>
> Thanks,
> sanjeewa.
>
> On Wed, Feb 7, 2018 at 11:57 AM, Uvindra Dias Jayasinha 
> wrote:
>
>> +1 Agreed with Nuwan about how subscriptions should be handled
>>
>>
>> Regarding the behavior of the Admin shared user, seems this is not
>> required because we already have an Admin REST API to change Application
>> ownership available in 2.2.0[1] as discussed in the mail thread[2]. This
>> addresses the requirement of what would happen if an App owner leaves the
>> organization. So we will only address the App Owner and Shared User
>> experience.
>>
>> [1]https://docs.wso2.com/display/AM2xx/apidocs/admin/#!/
>> operations#Application#applicationsApplicationIdChangeOwnerPost
>> [2][C4[]APIM] REST API for changing Owner of a Application
>>
>> On 7 February 2018 at 11:18, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Wed, Feb 7, 2018 at 11:14 AM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 Hi All,

 It seems that currently we do not have a clear definition in regarding
 what users can do with shared applications. This has been highlighted in[1]
 and the plan is to address this as part of the APIM 2.2.0 release.

 There are two types of users, the *App owner* who creates the App and
 the *shared user* who is able to view the App that is shared with them
 by the App owner.

 *Current issues*
 1. Product allows shared users to attempt updating Apps that are not
 owned by them, which leads to errors because they do not have the required
 permissions.

 2. Product allows shared users to delete Apps that are not owned by
 them which violate the Application ownership concept.

 The plan to address this is as follows

 *Solution*
 1. *App Owner *: Has ability to delete/update Apps owned by them.

 2. *Shared user*: Has only Read only access to Apps shared with
 them(cannot delete/update).
 Deletion and updation of Apps will be restricted at API Store UI level.
 App ownership will be   checked before performing App update/delete from
 server side in  order to   enforce this for REST API calls

>>>
>>> Shared user needs to view, remove and add subscriptions too IMO.
>>>

 3 *Admin shared user* : Has ability to delete/update Apps shared with
 them. The reason for this is to address practical issues that take place
 when the App owner leaves an organization and there needs to be some way to
 delete/update such an Application.

>>>
>>> +1
>>>


 Please give your feedback on the above.


 [1] https://github.com/wso2/product-apim/issues/2690
 --
 Regards,
 Uvindra

 Mobile: 33962

>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 33962
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>


-- 
Regards,
Uvindra

Mobile: 33962
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Clearly defining what operations users can perform on a shared application in APIM

[Sanjeewa Malalgoda]

Can shared users generate keys for the application? After first time if one
user regenerate application access key then it will effect others as we
revoke and generate application token.
I think regenerate option and application access token visibility also
should remove for above shared users. I think generate token with resource
owner grant by non app owner may cause issues.

Thanks,
sanjeewa.

On Wed, Feb 7, 2018 at 11:57 AM, Uvindra Dias Jayasinha 
wrote:

> +1 Agreed with Nuwan about how subscriptions should be handled
>
>
> Regarding the behavior of the Admin shared user, seems this is not
> required because we already have an Admin REST API to change Application
> ownership available in 2.2.0[1] as discussed in the mail thread[2]. This
> addresses the requirement of what would happen if an App owner leaves the
> organization. So we will only address the App Owner and Shared User
> experience.
>
> [1]https://docs.wso2.com/display/AM2xx/apidocs/admin/#!
> /operations#Application#applicationsApplicationIdChangeOwnerPost
> [2][C4[]APIM] REST API for changing Owner of a Application
>
> On 7 February 2018 at 11:18, Nuwan Dias  wrote:
>
>>
>>
>> On Wed, Feb 7, 2018 at 11:14 AM, Uvindra Dias Jayasinha > > wrote:
>>
>>> Hi All,
>>>
>>> It seems that currently we do not have a clear definition in regarding
>>> what users can do with shared applications. This has been highlighted in[1]
>>> and the plan is to address this as part of the APIM 2.2.0 release.
>>>
>>> There are two types of users, the *App owner* who creates the App and
>>> the *shared user* who is able to view the App that is shared with them
>>> by the App owner.
>>>
>>> *Current issues*
>>> 1. Product allows shared users to attempt updating Apps that are not
>>> owned by them, which leads to errors because they do not have the required
>>> permissions.
>>>
>>> 2. Product allows shared users to delete Apps that are not owned by them
>>> which violate the Application ownership concept.
>>>
>>> The plan to address this is as follows
>>>
>>> *Solution*
>>> 1. *App Owner *: Has ability to delete/update Apps owned by them.
>>>
>>> 2. *Shared user*: Has only Read only access to Apps shared with
>>> them(cannot delete/update).
>>> Deletion and updation of Apps will be restricted at API Store UI level.
>>> App ownership will be   checked before performing App update/delete from
>>> server side in  order to   enforce this for REST API calls
>>>
>>
>> Shared user needs to view, remove and add subscriptions too IMO.
>>
>>>
>>> 3 *Admin shared user* : Has ability to delete/update Apps shared with
>>> them. The reason for this is to address practical issues that take place
>>> when the App owner leaves an organization and there needs to be some way to
>>> delete/update such an Application.
>>>
>>
>> +1
>>
>>>
>>>
>>> Please give your feedback on the above.
>>>
>>>
>>> [1] https://github.com/wso2/product-apim/issues/2690
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
>



-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

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

Re: [Architecture] [GDPR] API Manager 3.0.0 GDPR Support

[Sanjeewa Malalgoda]

Hi All,
We were able to implement above suggested solution for API Manager 3.0.0
and test user flows successfully. Also we did integrations with identity
server 5.4.0 as authenticate service to verify external system
communication part. If user resides outside product domain(in tested
scenarion IS 5.4.0) we have to delete user from identity server side and
remove internal mapping. We do not have any plan to expose this
functionality as a web service to outside due to security concerns. APIM
components will be able to communicate with this through java API and get
mappings.

Do you have any suggestion to implement mechanism to mapping removal?
Should we expose API or java method to do that? Or let database admin to
remove mapping from database?
Appreciate suggestions.

Thanks,
sanjeewa.

On Wed, Feb 7, 2018 at 3:06 PM, Ishara Karunarathna 
wrote:

> Hi Sanjeewa,
>
> On Tue, Feb 6, 2018 at 12:33 PM, Sanjeewa Malalgoda 
> wrote:
>
>>
>>
>> On Mon, Feb 5, 2018 at 11:29 PM, Ishara Karunarathna 
>> wrote:
>>
>>> HI Sanjeewa,
>>>
>>> Pseudonym user ID (User ID) is not only limited to GDPR requirements
>>> but its really useful supporting features like changing userName, In C4 we
>>> do some workaround for this.
>>>
>>> I think this proposed approach is much similar to the pseudonym user ID
>>> implementation we did to support GDPR features in C4 based products. Where
>>> we have users in the system and later we introduce a mapping to those
>>> existing users. (Jayanga and Ruwan can add more on this).
>>>
>>> But IMO, I think in the new implementation we can provide first-class
>>> support for this. So we can create a user context with userID and
>>> displayName (Username), all the places we use the user ID, but when we
>>> display the users we can show the displayName or (username)
>>>
>> Yes we had discussion about subject and it was decided to use user pseudo
>> name in all places of the implementation. But whenever we need to show user
>> logged in name we will call user info or some other service and get display
>> name. That part will be handle from UI app and back end run time do not
>> need to worry about it. I think this implementation align with your
>> suggestion. Please let us know if you have any suggestion to above flow.
>>
> If this userID to display name conversion is not a frequest task this
> seems good
>
> Thanks,
> Ishara
>
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>> Thanks,
>>> Ishara
>>>
>>>
>>>
>>> On Fri, Feb 2, 2018 at 4:52 PM, Nuwan Dias  wrote:
>>>
 Hi all,

 When this is done up to some extent let's have a code review. I'm still
 struggling to understand the difference between user_id and pseudo name.
 And wondering whether we actually need a user_id concept if we implement
 something based on a pseudo name or vice versa.

 Just to be clear on the GDPR expectations, processing data with
 usernames in memory has absolutely no problem in terms of GDPR compliance.
 The only problem occurs when/if we persist a username somewhere. So as long
 as we don't log a username and don't write to a DB or file, we're good.
 Since developers have access to the username at the development time, they
 can still log it or write it to a DB or file anyway.

 @Shani, GDPR compliance rules apply over other rules. It's not intended
 to override other organizational rules. So if a particular organization has
 a policy to retain user data for 6 months and the user has consented to
 that, the user only has the "right to be forgotten" after the 6 months has
 passed. Until then the organization has the right to hold on to that data.

 Thanks,
 NuwanD.

 On Fri, Feb 2, 2018 at 11:11 AM, Sanjeewa Malalgoda 
 wrote:

> Nuwan, All,
> When we are calling with external systems such as scim we will use
> user ID. But internal flow manly goes with user name. Each time when rest
> API get hit with call we will call getUserName() method with http request
> and it resolve user name. That particular user name passed all through
> system and get recorded in databases, log files etc.
>
> Whenever we call SCIM etc we get relevant user id by calling identity
> provider and do following calls with user id. Still even with SCIM in 
> place
> user name is available all through implementation. Please see below code
> which we use to interact with external identity provider. As you can see 
> we
> use id only when communicate with identity providers. So above suggested
> implementation is a must.
>
> String userId = getIdentityProvider().getIdOfUser(userName);
> roles = new HashSet<>(getIdentityProvider().getRoleIdsOfUser(userId));
>
> What i'm doing is call follwing method before we need actual user
> name. So i had to place this line above code block.
> So i