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

[Maduranga Siriwardena]

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  > 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 are sharing those information through an SP we need to
 maintain those consents as well. WDYT ?

 In that case how can federated users download their consents ?

 On Mon, Jan 22, 2018 at 5:25 PM, Omindu Rathnaweera <
 omi...@wso2.com> wrote:

> Hi Maduranga,
>
> In the consent API we do not have the option to get multiple
> receipts, the API only returns a list of receipt IDs for a given 
> sear

Re: [Architecture] [MB4] Durable queue spilling mode

[Shazni Nazeer]

Hi Asanka,

+1 for the idea. I think this will bring down the memory footprint
significantly.

I would also like to suggest to have queue wise configurable in memory
limit, if that's not in your plan as of now. Say we have two queues A and
B. And we know queue A will be heavily populated and consumed compared to
B. So having a memory limit allocated to A being larger than B would
justify the demand for A's frequency of population and consumption.

On Tue, Feb 6, 2018 at 12:40 AM, Asanka Abeyweera  wrote:

> Hi Hasitha,
>
> On Tue, Feb 6, 2018 at 11:34 AM, Hasitha Hiranya 
> wrote:
>
>> Hi Asanka,
>>
>> +1 for the idea.
>>
>> Better if we can define the queue depth queue wise. If depth is
>> exceeded,  we have two options
>>
> Added an issue to track this (https://github.com/wso2/
> message-broker/issues/223)
>
>>
>> 1. drop the message (Qpid in-memory queues did this)
>> 2. spill data out.
>>
>> We do not drop messages in a durable queue. We just partially sync
> messages to memory from DB.
>
>
>> If we think about message is a bean, it will have fetch metadata and
>> fetch content methods. For inmemory messages those two methods will get
>> data from memory (inside that message object itself). For spilled out ones
>> we keep a id, so when loading to memory when queue moves, same method will
>> be called and DB is queried. But yeah, there is a performance issue if we
>> load message my message back to memory as we query DB message by message.
>>
>> Thanks
>>
>> On Tue, Feb 6, 2018 at 10:11 AM, Asanka Abeyweera 
>> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> *Problem*
>>> Currently, all the messages for queues are kept in memory without a
>>> limit. If we accumulate too many messages, the broker can go out of memory
>>> which we need to avoid. Therefore as a solution, we need to keep only a
>>> portion of the messages when a certain limit exceeds for a queue. That is,
>>> there will be two modes of operation.
>>>
>>> 1. Default mode - Messages are parallely persisted and put in to a in
>>> memory queue. The message delivery is done directly from messages published
>>> to in-memory queue storage
>>> 2. Spill mode - Published messages are directly persisted to database
>>> without putting in to in memory queue. Separately, messages are read from
>>> the database for delivery.
>>>
>>> But this change will introduce following issues.
>>>
>>>- Since we are keeping all the messages in memory, the reference
>>>counting was easy. But with this change, there can be a situation where 
>>> we
>>>do not have all copies of the same message in memory and we will have to 
>>> go
>>>for the database to see if there are any message references, which is not
>>>very efficient.
>>>- Since we now have two modes of operation and switching between the
>>>two modes need to be handled carefully. Otherwise, the message order can 
>>> be
>>>messed up.
>>>
>>>
>>>
>>> *Proposed Solution*
>>> I am planning to keep the message-queue reference information (queue
>>> attachment info) in memory along with the message ordering for all the
>>> messages for a queue. This will not add much memory footprint since we are
>>> only keeping the message ID and the queue attachment info.
>>>
>>>
>>> 1. In each queue buffer, we will put message with message data until we
>>> reach the buffer limit. Then only the message ID and queue attachement
>>> information is stored in the queue buffer to avoid filling memory.
>>> 2. When one of the messages in the queue buffer is acknowledged we, will
>>> proceed the buffer limit cursor and send message data read requests to fill
>>> the message data.
>>> 3. When the message data is read from database and filled, the
>>> deliverable limit cursor will be progressed to make that message
>>> deliverable.
>>>
>>> When we start a node only the message id and queue attachment
>>> information is loaded. The handling logic will then asynchronously load
>>> message data to memory.
>>>
>>> WDYT?
>>> ​
>>> --
>>> Asanka Abeyweera
>>> Associate Technical Lead
>>> WSO2 Inc.
>>>
>>> Phone: +94 712228648 <+94%2071%20222%208648>
>>> Blog: a5anka.github.io
>>>
>>> 
>>>
>>
>>
>>
>> --
>> *Hasitha Abeykoon*
>> Associate Technical Lead; WSO2, Inc.; http://wso2.com
>> *cell:* *+94 719363063*
>> *blog: **abeykoon.blogspot.com* 
>>
>>
>
>
> --
> Asanka Abeyweera
> Associate Technical Lead
> WSO2 Inc.
>
> Phone: +94 712228648 <+94%2071%20222%208648>
> Blog: a5anka.github.io
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Shazni Nazeer

Mob : +94 37331
LinkedIn : http://lk.linkedin.com/in/shazninazeer

Blogs :

https://medium.com/@mshazninazeer
http://shazninazeer.blogspot.com


___
Architecture mailing list
Architecture@ws

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

[Chiran Wijesekara]

Hi all,

we have decided to create a REST endpoint for the purpose of claim
management of WSO2 Identity Server future versions. Currently,
ClaimMetaDataManagement Service is exposed as a SOAP endpoint as per the
documentation provided under [1].

As the first step toward the above effort, the prospective REST API will be
designed with the help of Swagger. Further, this step has already been
started and the thread will be updated with latest details.

[1] https://docs.wso2.com/display/IS540/Managing+Claims+with+APIs

Thank You.
-- 
*Chiran Wijesekara*


*Software Engineering Intern | WSO2*Email: chir...@wso2.com
Mobile: +94712990173web: www.wso2.com

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

Re: [Architecture] Support FIDP initiated logout with new identity framework

[Dimuthu Leelarathne]

Hi Darshana,

Would the core IS team provide a method for this (terminate framework level
session) functionality?

thanks,
Dimuthu


On Wed, Feb 7, 2018 at 2:33 PM, Malithi Edirisinghe 
wrote:

>
>
> On Wed, Feb 7, 2018 at 2:32 AM, Johann Nallathamby 
> wrote:
>
>> It is in fact an inbound connector. So +1 to use the inbound framework
>> and write a InboundProcessor to process this request. This way we can have
>> an abstract FederatedIdPInitiatedLogoutProcessor (you may come up with a
>> different name) that will handle the logout specific logic in
>> authentication framework and extend it to multiple protocol specific
>> processors which will handle protocol specific logout logic.
>>
>
>  Will we need a processor in the framework. Rather, I think there should
> be a service in framework for session related operations like terminate
> session, check if there's a valid session etc.
> The protocol specific processor will handle requests and call the
> framework service for session termination. Upon the specific operation in
> framework service, framework will make sure to trigger other operation
> specific tasks. For example, upon session termination trigger the session
> termination event, do cleanups etc.
> Introduction, of such a service will be useful for many other use cases I
> think. For example, extend framework session, terminate session upon
> critical events and all sub operations can be triggered centrally.
> WDYT?
>
>
>> Whether it should come inside identity-inbound-auth-saml or
>> identity-outbound-auth-samlsso, I think will have to go with what the
>> majority feels, because this use case is a hybrid between both, and the
>> current naming convention of repos didn't take this into consideration when
>> originally naming it. It can be argued both ways,
>> 1. Since this is an inbound request to IS, it should go under
>> identity-inbound-auth-saml
>> 2. Since this is a dealing with the session between IS and federated IdP,
>> and all the IdentityProvider module dependencies are in
>> identity-outbound-auth-samlsso, and since authentication between SP - IS
>> and IS - IDP should be decoupled, it should go under
>> identity-outbound-auth-samlsso.
>>
>> Both the above seem to have equal amount of convincing power to me :).
>> Technically I would prefer going with 2 above, accepting the fact that
>> "outbound" part in the naming is not the best, because we didn't consider
>> such use case in the begining and hoping one day we will rename the repo to
>> be more accurate :).
>>
>> Regards,
>> Johann.
>>
>> On Tue, Feb 6, 2018 at 11:47 PM, Hasintha Indrajee 
>> wrote:
>>
>>> According to the analysis, it seems like logout requests from SPs and
>>> logout requests from IDPs look similar. @Kanapriya, were you able to skim
>>> through specs and see whether there are differences ?.
>>>
>>> Also on the other hand when we have a look towards our new framework,
>>> this looks more like an inbound connector because the request is initiated
>>> from a third party caller. Hence it's more inbound as per our framework.
>>> WDYT ?. Also if we are to follow this approach we need to avoid going
>>> through loops.
>>>
>>> On Tue, Feb 6, 2018 at 5:09 PM, Kanapriya Kuleswararajan <
>>> kanapr...@wso2.com> wrote:
>>>
 Hi All,

 For the POC [1], I have registered a new servlet in
 identity-outbound-auth-samlsso authenticator and try out the FIDP initiated
 logout flow by removing the session id which is associated with the earlier
 login.

 Now  I have tried to move the POC [1] code to support with the new
 identity framework.

 Here, we have a concern that whether we need to move the code to the
 *identity-inbound-auth-saml* or *identity-outbound-auth-samlsso*.

 IMO, we need to handle the logout request which is initiated by FIDP
 inside identity-inbound-auth-saml. Please find the reasons for that :

- Generally, whenever the request comes to IS from External system,
it will be handle by the Inbound flow (identity-inbound-auth-saml).
- I have configured IS with two service providers (Travelocity,
Avis) and try out the logout flow.
- Where I'm able to see the SAML Logout Request which is exactly
same as SAML Logout Request which is initiated by FIDP.
- Since both SAML Logout Request are same, we can move code to
identity-inbound-auth-saml.

 Appreciate your thoughts on this.

 [1] Federated IdP Initiated Logout

 Thanks,
 Kanapriya

 Kanapriya Kuleswararajan
 Software Engineer
 Mobile : - 0774894438 <077%20489%204438>
 Mail : - kanapr...@wso2.com
 LinkedIn : - https://www.linkedin.com/in/kanapriya-kules-94712685/
 WSO2, Inc.
 lean . enterprise . middleware


>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead 

Re: [Architecture] Support FIDP initiated logout with new identity framework

[Kanapriya Kuleswararajan]

Hi All,

For the moment, as per the off-line discussion with Malithi and Johann, I
have tried to move the code to *identity-outbound-auth-samlsso*
 to make this feature compatible with new identity framework.

But I have get the code [1] (without adding the changes related to this
feature) and replace the jar org.wso2.carbon.identity.
application.authenticator.samlsso-5.1.8.jar with org.wso2.carbon.identity.
authenticator.outbound.saml2sso-6.0.0-SNAPSHOT.jar in dropins directory and
try out the SSO scenario.

Where I have logged_in via avis, with the same SSO session couldn't login
with travelcoity. Got the error as below in the back end .

[2018-02-07 22:04:32,969] DEBUG
{org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet}
-  Query string : SAMLRequest=nZNPb9pAEMXv%2FRTW3sHGoIauMBEFRUVKKwqkh96G9
RBvun%2FcnTVJvn12bWhR1SLU63jmzezvPU9uX7RKDuhIWlOwQT9jCRphS2keC%
2FawveuN2e303YRAq5rPGl%2BZNf5skHwyI0Lnw9jcGmo0ug26gxT
4sL4vWOV9zdNUWQGqsuT5OBtnqXdwwFCT%2FrUvrE4rq7H%
2FRDVLFkFRGvDtFXGYwrSkQWzjH0ajYRovILIsubNOYHtJwfagCFmyXBRMC%
2FtDAhixC6JKaolmp0ttNADsHnVldk%2FSygpCN62ASB7w9zxRg0tDHowvWJ4
Nxr0s72U328F7PhzxfNwf3oy%2Bs2TlrLfCqo%2FSdIAaZ7gFksQNaCTuBd%2FMPt%
2FzvJ%2FxXddE%2FNN2u%2BqtsZQOhWfJtxPsPMIO%2BA3xFu9lufq4m02PZrRHu%
2BsF4OQXm%2F7hwyQ9V%2Bz085p%2FCRLLxcoqKV6TmVL2ee4QfMDmXYOt
ERr85aWxIsvevm3ldXw6eTQBw2YV9b82oOReoitYt%2F2cSH4tkvTXzcdwYtkGJCTT44tP5l
bX4CRF6vgC0YX%2F2NIt4efKcxWornF%2FJne1CRfbBBdROpRjVp%
2BtK2P2Qn6w3DowVFvnO9v%2Bes%2B0%2B%2FYvINOT4%2Bc%2F9PQN&SigAlg=http%3A%2F%
2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=
bcZoO0XXWmWtBnihuSERjfDuv6cyZU41Gxo5qXD5t4FM5NgtKAiRqDYgoVfYEGEOWukUwB054mZ%
2F4E69OK90rTh8q7p05xUmBxa1Z4GASfCxlpdfLPLCCVktJCYJXwHBVp38vz
EZGnxPhobNsZJYveZGEG2gHw4%2BZQWf8G%2BQw8%2F97yRoPb9Xh%
2F90xgkVtUIr2OZb5hvxLMr5yDnVMP9D3gAfTGkW%2F2YKQRDQMeSoVExVypZluccuEtZ9O
NUT15YI8ZM0JLCafP9vbKQ2wMuv3u6qRU5Q9mDFmMDYh1f7RQCwNOkhlBArk
eo3qdaPlTaeL3O9Z0sPgrDGaVtJcInXTw%3D%3D
[2018-02-07 22:04:32,973] DEBUG
{org.wso2.carbon.identity.sso.saml.util.SAMLSSOUtil}
-  Request message 
http://localhost:8080/
travelocity.com/home.jsp" Destination="https://is1.com:9443/samlsso";
ForceAuthn="false" ID="mcokiaancbomelimienbmdmnmaaabgmhnbjioiha"
IsPassive="false" IssueInstant="2018-02-07T16:34:28.374Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">travelocity.com
urn:
oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport<
/samlp:AuthnRequest>
[2018-02-07 22:04:32,975] DEBUG {org.wso2.carbon.identity.sso.
saml.validators.SSOAuthnRequestAbstractValidator} -  Thread local tenant
domain is set to: carbon.super
[2018-02-07 22:04:32,976] DEBUG {org.wso2.carbon.identity.sso.
saml.validators.SPInitSSOAuthnRequestValidator} -  Authentication Request
Validation is successful..
[2018-02-07 22:04:32,981] ERROR {org.wso2.carbon.identity.
application.authentication.framework.handler.step.impl.DefaultStepHandler}
-  Authenticator is null
[2018-02-07 22:04:32,986] DEBUG
{org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet}
-  Query string : SAMLRequest=nZNPb9pAEMXv%2FRTW3sHGoIauMBEFRUVKKwqkh96G9
RBvun%2FcnTVJvn12bWhR1SLU63jmzezvPU9uX7RKDuhIWlOwQT9jCRphS2keC%
2FawveuN2e303YRAq5rPGl%2BZNf5skHwyI0Lnw9jcGmo0ug26gxT
4sL4vWOV9zdNUWQGqsuT5OBtnqXdwwFCT%2FrUvrE4rq7H%
2FRDVLFkFRGvDtFXGYwrSkQWzjH0ajYRovILIsubNOYHtJwfagCFmyXBRMC%
2FtDAhixC6JKaolmp0ttNADsHnVldk%2FSygpCN62ASB7w9zxRg0tDHowvWJ4
Nxr0s72U328F7PhzxfNwf3oy%2Bs2TlrLfCqo%2FSdIAaZ7gFksQNaCTuBd%2FMPt%
2FzvJ%2FxXddE%2FNN2u%2BqtsZQOhWfJtxPsPMIO%2BA3xFu9lufq4m02PZrRHu%
2BsF4OQXm%2F7hwyQ9V%2Bz085p%2FCRLLxcoqKV6TmVL2ee4QfMDmXYOt
ERr85aWxIsvevm3ldXw6eTQBw2YV9b82oOReoitYt%2F2cSH4tkvTXzcdwYtkGJCTT44tP5l
bX4CRF6vgC0YX%2F2NIt4efKcxWornF%2FJne1CRfbBBdROpRjVp%
2BtK2P2Qn6w3DowVFvnO9v%2Bes%2B0%2B%2FYvINOT4%2Bc%2F9PQN&SigAlg=http%3A%2F%
2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-sha1&Signature=
bcZoO0XXWmWtBnihuSERjfDuv6cyZU41Gxo5qXD5t4FM5NgtKAiRqDYgoVfYEGEOWukUwB054mZ%
2F4E69OK90rTh8q7p05xUmBxa1Z4GASfCxlpdfLPLCCVktJCYJXwHBVp38vz
EZGnxPhobNsZJYveZGEG2gHw4%2BZQWf8G%2BQw8%2F97yRoPb9Xh%
2F90xgkVtUIr2OZb5hvxLMr5yDnVMP9D3gAfTGkW%2F2YKQRDQMeSoVExVypZluccuEtZ9O
NUT15YI8ZM0JLCafP9vbKQ2wMuv3u6qRU5Q9mDFmMDYh1f7RQCwNOkhlBArk
eo3qdaPlTaeL3O9Z0sPgrDGaVtJcInXTw%3D%3D
[2018-02-07 22:04:32,986] ERROR
{org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet}
-  Cannot find AuthenticationResult from the cache
[2018-02-07 22:04:32,987] DEBUG
{org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet}
-  No SaaS SAML service providers found for the issuer : travelocity.com.
Checking for SAML service providers registered in tenant domain :
carbon.super
[2018-02-07 22:04:32,987] DEBUG
{org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet}
-  Authentication result data not found for key : 3ec4336c-d0cd-41d8-88d9-
829901db205b
[2018-02-07 22:04:32,987] ERROR
{org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet}
-  Error when processing the authentication request!
o

Re: [Architecture] CLI Client for the Message Broker

[Dakshika Jayathilaka]

Hi All,

IMO we need to support basic level features such as *--help*, *--version*
and *--verbose* on each CLI tool that we are building.

Also, we need to think about the standard output for each scenario as well.
Shall we add few samples for that as well?

Regards,

*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911

On Wed, Feb 7, 2018 at 10:24 AM, Eranda Rajapakshe  wrote:

> Hi Imesh,
>
> Yes, we are going to include help command into the client. Thanks for the
> reference, it looks interesting.
>
> Thanks,
>
> On Wed, Feb 7, 2018 at 10:13 AM, Imesh Chandrasiri 
> wrote:
>
>> Hi Eranda,
>>
>> A small clarification on the commands. Could these have a '--help'
>> command where the syntax and the usage of the command is printed? IMHO it
>> would benefit the user to figure out the command usage then and there
>> without having to read the documentation. This is a nice article[1
>> ] on some UX views of a CLI.
>>
>> [1] - https://zapier.com/engineering/how-to-cli/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Eranda Rajapakshe*
> Software Engineer
> WSO2 Inc.
> Mobile : +94784822608
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Ishara Karunarathna]

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 can use pseudo name all over the implementation.

 String userName =
 APIUtils.getLoggedInUsernameFromPseudoName(user);

 Thanks,
 sanjeewa.

 On Fri, Feb 2, 2018 at 10:07 AM, Malintha Amarasinghe <
 malint...@wso2.com> wrote:

> Hi Nuwan,
>
> Looks like there are several places we are using usernames as it is.
> Eg: provider, business owner, technical owner names in API table,
> CREATED_BY, UPDATED_BY audit columns in all the resource tables. There can
> be several other places. We need to fix those places to use UUIDs. I guess
> we can use this UUID itself as the pseudo name.
>
> When SCIM comes into place, we will be getting a UUID for each user.
> We should be able to store it instead of the username in above places. But
> not sure whether we need to (persist/keep in memory in a map) username -
> UUID mapping in APIM side too, otherwise we need to give SCIM call to get
> the real username when needed all the time.
>
> On Fri, Feb 2, 2018 at 8:55

Re: [Architecture] Support FIDP initiated logout with new identity framework

[Johann Nallathamby]

On Wed, Feb 7, 2018 at 2:33 PM, Malithi Edirisinghe 
wrote:

>
>
> On Wed, Feb 7, 2018 at 2:32 AM, Johann Nallathamby 
> wrote:
>
>> It is in fact an inbound connector. So +1 to use the inbound framework
>> and write a InboundProcessor to process this request. This way we can have
>> an abstract FederatedIdPInitiatedLogoutProcessor (you may come up with a
>> different name) that will handle the logout specific logic in
>> authentication framework and extend it to multiple protocol specific
>> processors which will handle protocol specific logout logic.
>>
>
>  Will we need a processor in the framework. Rather, I think there should
> be a service in framework for session related operations like terminate
> session, check if there's a valid session etc.
> The protocol specific processor will handle requests and call the
> framework service for session termination. Upon the specific operation in
> framework service, framework will make sure to trigger other operation
> specific tasks. For example, upon session termination trigger the session
> termination event, do cleanups etc.
> Introduction, of such a service will be useful for many other use cases I
> think. For example, extend framework session, terminate session upon
> critical events and all sub operations can be triggered centrally.
> WDYT?
>

+1. That should be the ideal approach.


>
>
>> Whether it should come inside identity-inbound-auth-saml or
>> identity-outbound-auth-samlsso, I think will have to go with what the
>> majority feels, because this use case is a hybrid between both, and the
>> current naming convention of repos didn't take this into consideration when
>> originally naming it. It can be argued both ways,
>> 1. Since this is an inbound request to IS, it should go under
>> identity-inbound-auth-saml
>> 2. Since this is a dealing with the session between IS and federated IdP,
>> and all the IdentityProvider module dependencies are in
>> identity-outbound-auth-samlsso, and since authentication between SP - IS
>> and IS - IDP should be decoupled, it should go under
>> identity-outbound-auth-samlsso.
>>
>> Both the above seem to have equal amount of convincing power to me :).
>> Technically I would prefer going with 2 above, accepting the fact that
>> "outbound" part in the naming is not the best, because we didn't consider
>> such use case in the begining and hoping one day we will rename the repo to
>> be more accurate :).
>>
>> Regards,
>> Johann.
>>
>> On Tue, Feb 6, 2018 at 11:47 PM, Hasintha Indrajee 
>> wrote:
>>
>>> According to the analysis, it seems like logout requests from SPs and
>>> logout requests from IDPs look similar. @Kanapriya, were you able to skim
>>> through specs and see whether there are differences ?.
>>>
>>> Also on the other hand when we have a look towards our new framework,
>>> this looks more like an inbound connector because the request is initiated
>>> from a third party caller. Hence it's more inbound as per our framework.
>>> WDYT ?. Also if we are to follow this approach we need to avoid going
>>> through loops.
>>>
>>> On Tue, Feb 6, 2018 at 5:09 PM, Kanapriya Kuleswararajan <
>>> kanapr...@wso2.com> wrote:
>>>
 Hi All,

 For the POC [1], I have registered a new servlet in
 identity-outbound-auth-samlsso authenticator and try out the FIDP initiated
 logout flow by removing the session id which is associated with the earlier
 login.

 Now  I have tried to move the POC [1] code to support with the new
 identity framework.

 Here, we have a concern that whether we need to move the code to the
 *identity-inbound-auth-saml* or *identity-outbound-auth-samlsso*.

 IMO, we need to handle the logout request which is initiated by FIDP
 inside identity-inbound-auth-saml. Please find the reasons for that :

- Generally, whenever the request comes to IS from External system,
it will be handle by the Inbound flow (identity-inbound-auth-saml).
- I have configured IS with two service providers (Travelocity,
Avis) and try out the logout flow.
- Where I'm able to see the SAML Logout Request which is exactly
same as SAML Logout Request which is initiated by FIDP.
- Since both SAML Logout Request are same, we can move code to
identity-inbound-auth-saml.

 Appreciate your thoughts on this.

 [1] Federated IdP Initiated Logout

 Thanks,
 Kanapriya

 Kanapriya Kuleswararajan
 Software Engineer
 Mobile : - 0774894438 <077%20489%204438>
 Mail : - kanapr...@wso2.com
 LinkedIn : - https://www.linkedin.com/in/kanapriya-kules-94712685/
 WSO2, Inc.
 lean . enterprise . middleware


>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile: *+94 77 7776

Re: [Architecture] Support FIDP initiated logout with new identity framework

[Malithi Edirisinghe]

On Wed, Feb 7, 2018 at 2:32 AM, Johann Nallathamby  wrote:

> It is in fact an inbound connector. So +1 to use the inbound framework and
> write a InboundProcessor to process this request. This way we can have an
> abstract FederatedIdPInitiatedLogoutProcessor (you may come up with a
> different name) that will handle the logout specific logic in
> authentication framework and extend it to multiple protocol specific
> processors which will handle protocol specific logout logic.
>

 Will we need a processor in the framework. Rather, I think there should be
a service in framework for session related operations like terminate
session, check if there's a valid session etc.
The protocol specific processor will handle requests and call the framework
service for session termination. Upon the specific operation in framework
service, framework will make sure to trigger other operation specific
tasks. For example, upon session termination trigger the session
termination event, do cleanups etc.
Introduction, of such a service will be useful for many other use cases I
think. For example, extend framework session, terminate session upon
critical events and all sub operations can be triggered centrally.
WDYT?


> Whether it should come inside identity-inbound-auth-saml or
> identity-outbound-auth-samlsso, I think will have to go with what the
> majority feels, because this use case is a hybrid between both, and the
> current naming convention of repos didn't take this into consideration when
> originally naming it. It can be argued both ways,
> 1. Since this is an inbound request to IS, it should go under
> identity-inbound-auth-saml
> 2. Since this is a dealing with the session between IS and federated IdP,
> and all the IdentityProvider module dependencies are in
> identity-outbound-auth-samlsso, and since authentication between SP - IS
> and IS - IDP should be decoupled, it should go under
> identity-outbound-auth-samlsso.
>
> Both the above seem to have equal amount of convincing power to me :).
> Technically I would prefer going with 2 above, accepting the fact that
> "outbound" part in the naming is not the best, because we didn't consider
> such use case in the begining and hoping one day we will rename the repo to
> be more accurate :).
>
> Regards,
> Johann.
>
> On Tue, Feb 6, 2018 at 11:47 PM, Hasintha Indrajee 
> wrote:
>
>> According to the analysis, it seems like logout requests from SPs and
>> logout requests from IDPs look similar. @Kanapriya, were you able to skim
>> through specs and see whether there are differences ?.
>>
>> Also on the other hand when we have a look towards our new framework,
>> this looks more like an inbound connector because the request is initiated
>> from a third party caller. Hence it's more inbound as per our framework.
>> WDYT ?. Also if we are to follow this approach we need to avoid going
>> through loops.
>>
>> On Tue, Feb 6, 2018 at 5:09 PM, Kanapriya Kuleswararajan <
>> kanapr...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> For the POC [1], I have registered a new servlet in
>>> identity-outbound-auth-samlsso authenticator and try out the FIDP initiated
>>> logout flow by removing the session id which is associated with the earlier
>>> login.
>>>
>>> Now  I have tried to move the POC [1] code to support with the new
>>> identity framework.
>>>
>>> Here, we have a concern that whether we need to move the code to the
>>> *identity-inbound-auth-saml* or *identity-outbound-auth-samlsso*.
>>>
>>> IMO, we need to handle the logout request which is initiated by FIDP
>>> inside identity-inbound-auth-saml. Please find the reasons for that :
>>>
>>>- Generally, whenever the request comes to IS from External system,
>>>it will be handle by the Inbound flow (identity-inbound-auth-saml).
>>>- I have configured IS with two service providers (Travelocity,
>>>Avis) and try out the logout flow.
>>>- Where I'm able to see the SAML Logout Request which is exactly
>>>same as SAML Logout Request which is initiated by FIDP.
>>>- Since both SAML Logout Request are same, we can move code to
>>>identity-inbound-auth-saml.
>>>
>>> Appreciate your thoughts on this.
>>>
>>> [1] Federated IdP Initiated Logout
>>>
>>> Thanks,
>>> Kanapriya
>>>
>>> Kanapriya Kuleswararajan
>>> Software Engineer
>>> Mobile : - 0774894438 <077%20489%204438>
>>> Mail : - kanapr...@wso2.com
>>> LinkedIn : - https://www.linkedin.com/in/kanapriya-kules-94712685/
>>> WSO2, Inc.
>>> lean . enterprise . middleware
>>>
>>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>
>>
>
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile: *+94 77 7776950*
> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
> *
> Medium: *https://medium.com/@johann_nallathamby
> *
> Twitter: *@dj_nallaa*
>



-- 

*M