Re: [Architecture] Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

[Nuwandi Wickramasinghe]

Hi Asela,

In that case you need to customize PostAuthenticationHandler
implementation. Default implementation is found in [1].

Please note that there's a bug in extension point naming reported in [2].
Therefore when configuring the extension class, you will have give the
extension class as an   under  in
application-authentication.xml

[1]
https://github.com/wso2/carbon-identity-framework/blob/master/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/request/impl/DefaultPostAuthenticationHandler.java
[2] https://wso2.org/jira/browse/IDENTITY-5575

best regards
Nuwandi

On Tue, Jan 24, 2017 at 12:42 PM, Asela Pathberiya  wrote:

>
>
> On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe <
> nuwan...@wso2.com> wrote:
>
>> Hi Asela,
>>
>> This does not work in 5.3.0.
>>
>> IS will pop up for the mandatory claims requested by the Service Provider
>> if they are not sent by the federated authenticator. But the claims
>> provided by the user at this step are not persisted for federated users,
>>  even if they are provisioned to IS. I think we have missed that part and
>> better to persist these values in provisioned user profile.
>>
>> However, the mandatory claim configuration in Service Provider indicates
>> this claim is mandatory to access that particular SP. Should we have a
>> different configuration to define mandatory claims for provisioning ?
>>
>
> Yes. it may be different..  There are required claims based on the
> provisioning user store. Basically Mandatory claims for JIT   Can we fix
> this for future release ?
>
> However;  if i want to achieve this using WSO2IS 5.3.0  what is extension
> to customize ?  Is it JIT provisioning handler  or some other ?  (Assume
> that i want to JIT claims which are popup/requested by SP)
>
> Thanks,
> Asela.
>
>
>>
>> thanks
>> Nuwandi
>>
>> On Mon, Jan 23, 2017 at 6:41 PM, Asela Pathberiya  wrote:
>>
>>> Hi Nuwandi
>>>
>>> Can WSO2IS popup for user claims which must be provision in to the local
>>> user store (JIT provisioning) ?
>>>
>>> If federated claims are not enough to update the user store, then it is
>>> assume that WSO2IS can popup for addition claims & persisted.. Does it work
>>> with WSO2IS 5.3.0 ?
>>>
>>> Thanks,
>>> Asela.
>>>
>>> On Sat, Jan 14, 2017 at 11:37 PM, Nuwandi Wickramasinghe <
>>> nuwan...@wso2.com> wrote:
>>>
 Sorry for the late reply. Please find the inline comments.

 thanks and regards.

 On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker <
 jochen.traunec...@googlemail.com> wrote:

> Hi,
>
> Is the user considered as successfully authenticated even if he will
> never provide the asked claims? What will be send back to SP if user is 
> NOT
> providing any claims?
>
 No. User will not be authenticated and he will not be able access
 service provider. But the user will be asked to provide the claims only if
 they are marked as "Mandatory" in the SP configuration in Identity Server.
 You can add requested claims in SP configuration without marking them as
 mandatory. In that case IS will authenticate user and send those requested
 claims to the SP if they are available in user profile.

 There is the scenario with WebSSO and SP1 asking for claims SP2 is not
> interested in. While establishing the very first authentication session 
> for
> user X with SP1, that user X might be successfully authenticated but will
> not share additional claims. Assuming some DENY response will be send back
> to SP1 and user moves forward to SP2, will he then be considered as 
> already
> successfully authenticated ?
>
 As per the current implementation, if SP1 configuration has any
 mandatory claims, user will not be authenticated until he provides them.
 User will have to login in to SP2

>
> Besides the "provide more claims" step we can expect a "confirm to
> share claims with SP-X" become a requirement, too. This could get handled
> in the handlePostAuthentication() method, too, but then expectation is 
> that
> although a DENY is send to SP-1 (when user doesn't want to share
> information) the user is considered successfully authenticated in IdP (IS)
> with e.g. SP-2 he already confirmed before 
>
 We do not have this implemented. Basically, if SP configuration has
 marked any claim as mandatory, we consider that service provider cannot be
 used without that attribute. Therefore user needs to share that value with
 that particular SP

>
> Thanks,
> Jochen
>
> Harsha Thirimanna  schrieb am Mi. 2. Nov. 2016 um
> 06:19:
>
>> After , the use get authenticated and try to login to same sp by
>> using different tab also we may have to prompt the input screen because
>> there may be additional 

Re: [Architecture] [C5][APIM] Full Text Search

[Malith Jayasinghe]

Ok. You could also consider writing a small micro bench-mark and get the
performance numbers (instead of testing this using an external load
generator). This will minimize the impact of other components/layers on the
results.

On Tue, Jan 24, 2017 at 9:56 AM, Rajith Roshan  wrote:

> Hi Malith,
>
> Thanks for your input. I have changed the jmeter scripts according to you
> instructions.
> I was using a oracle docker instance in my local machine. I have changed
> it to a remote oracle database. Now the latency is much less. I will share
> all the performance numbers once I have finished collecting them for
> oracle, mssql, mysql and postgres databases.
>
> Thanks!
> Rajith
>
> On Tue, Jan 24, 2017 at 9:46 AM, Malith Jayasinghe 
> wrote:
>
>> @Rajith
>>
>> As per the offline discussion we had regarding the performance evaluation
>> (using JMETER) of the two methods:
>> - use 2 separate thread groups for evaluating the performance of 2 DB
>> based search methods
>> - run each thread group sequentially
>> - run the test for a longer period under different concurrency level and
>> record the latency and TPS
>>
>> With regard to the long latencies you are noticing, we need to figure out
>> if this is related to the database query/queries or something else. To do a
>> quick test: simply log the execution time of the query/queries. If the
>> execution times are high (or have spikes) then we can try to optimize the
>> DB query. Otherwise we have to do some further investigations.
>>
>> Thanks
>>
>> Malith
>>
>>
>>
>>
>>
>>
>> On Sat, Jan 14, 2017 at 10:43 PM, Nuwan Dias  wrote:
>>
>>> File system based indexers bring new challenges in the container world.
>>> It also poses challenges in HA (multinode) and multi regional deployments.
>>> Therefore if we're selecting a solr indexing approach, the only practical
>>> solution is to go with a solr server based architecture.
>>>
>>> Even with a solr server assisted architecture, we still have
>>> complexities when dealing with multi regional deployments. Also since API
>>> artifacts reside in the database, if we're loading search results from an
>>> index, we have to sync the permissions of the artifacts in the index too.
>>> Plus this makes the deployment complex.
>>>
>>> Given the complexities that have to be addressed in an indexing
>>> solution, I'd prefer to opt with the DB based search at least to start off
>>> with. Since APIs and their permissions are both maintained in the DB, it
>>> would be much simple if the search also works on that. Unlike in C4 this
>>> database will only have data of 1 tenant. Hence we're not expecting the API
>>> count to be in the thousands. Therefore I think searching through the
>>> database should be feasible.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Sat, 14 Jan 2017 at 8:27 am, Chandana Napagoda 
>>> wrote:
>>>
 Hi Rajith,

 I believe indexing based approach is more suitable for any search
 solution because its design is to support fast search results. If you use
 database search, you have to use multiple DB indexes to improve search
 performance, and that will reduce the performance of insert operations.

 I think, REG_LOG kind of history table is not necessary for APIM
 product, since it is totally aware of the APIM artifacts(APIs, Docs, forum
 posts) and you can directly connect to the DB[1] from the text search
 engine and index the resources. As per the Solr documentation, it is
 capable of importing only the new additions(delta) for indexing.

 [1]. https://cwiki.apache.org/confluence/display/solr/Uploading+S
 tructured+Data+Store+Data+with+the+Data+Import+Handler

 Regards,
 Chandana


 On Fri, Jan 13, 2017 at 11:44 AM, Rajith Roshan 
 wrote:

 Hi all,

 We are currently evaluating how to perform full text search at the
 database level for C5 based API Manager. We will be evaluating this for
 different types of databases to find their implementation complexities and
 limitations.
 Other option available for us to use indexing based approach (use Solr)

 *Database full text search *
 *Pros*

- Less complications when using container based approach
- Clustering will require only database syncing.
- No need to maintain and ship external search engine.

 *Cons*

- Implementation may vary significantly based on the database type
- There can be limitation in full text search for particular
database types (For ex: mysql full text support only prefix search)
- Queries will differ based on database type
- Document search will not be available, because they are stored as
blobs


 *Indexing based approach *
 *Pros*

- Document search
- Search will be efficient (No need to access database)

 *Cons*

- Since indexing data is written to file system , when going for
 

Re: [Architecture] Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

[Asela Pathberiya]

On Mon, Jan 23, 2017 at 10:04 PM, Nuwandi Wickramasinghe 
wrote:

> Hi Asela,
>
> This does not work in 5.3.0.
>
> IS will pop up for the mandatory claims requested by the Service Provider
> if they are not sent by the federated authenticator. But the claims
> provided by the user at this step are not persisted for federated users,
>  even if they are provisioned to IS. I think we have missed that part and
> better to persist these values in provisioned user profile.
>
> However, the mandatory claim configuration in Service Provider indicates
> this claim is mandatory to access that particular SP. Should we have a
> different configuration to define mandatory claims for provisioning ?
>

Yes. it may be different..  There are required claims based on the
provisioning user store. Basically Mandatory claims for JIT   Can we fix
this for future release ?

However;  if i want to achieve this using WSO2IS 5.3.0  what is extension
to customize ?  Is it JIT provisioning handler  or some other ?  (Assume
that i want to JIT claims which are popup/requested by SP)

Thanks,
Asela.


>
> thanks
> Nuwandi
>
> On Mon, Jan 23, 2017 at 6:41 PM, Asela Pathberiya  wrote:
>
>> Hi Nuwandi
>>
>> Can WSO2IS popup for user claims which must be provision in to the local
>> user store (JIT provisioning) ?
>>
>> If federated claims are not enough to update the user store, then it is
>> assume that WSO2IS can popup for addition claims & persisted.. Does it work
>> with WSO2IS 5.3.0 ?
>>
>> Thanks,
>> Asela.
>>
>> On Sat, Jan 14, 2017 at 11:37 PM, Nuwandi Wickramasinghe <
>> nuwan...@wso2.com> wrote:
>>
>>> Sorry for the late reply. Please find the inline comments.
>>>
>>> thanks and regards.
>>>
>>> On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker <
>>> jochen.traunec...@googlemail.com> wrote:
>>>
 Hi,

 Is the user considered as successfully authenticated even if he will
 never provide the asked claims? What will be send back to SP if user is NOT
 providing any claims?

>>> No. User will not be authenticated and he will not be able access
>>> service provider. But the user will be asked to provide the claims only if
>>> they are marked as "Mandatory" in the SP configuration in Identity Server.
>>> You can add requested claims in SP configuration without marking them as
>>> mandatory. In that case IS will authenticate user and send those requested
>>> claims to the SP if they are available in user profile.
>>>
>>> There is the scenario with WebSSO and SP1 asking for claims SP2 is not
 interested in. While establishing the very first authentication session for
 user X with SP1, that user X might be successfully authenticated but will
 not share additional claims. Assuming some DENY response will be send back
 to SP1 and user moves forward to SP2, will he then be considered as already
 successfully authenticated ?

>>> As per the current implementation, if SP1 configuration has any
>>> mandatory claims, user will not be authenticated until he provides them.
>>> User will have to login in to SP2
>>>

 Besides the "provide more claims" step we can expect a "confirm to
 share claims with SP-X" become a requirement, too. This could get handled
 in the handlePostAuthentication() method, too, but then expectation is that
 although a DENY is send to SP-1 (when user doesn't want to share
 information) the user is considered successfully authenticated in IdP (IS)
 with e.g. SP-2 he already confirmed before 

>>> We do not have this implemented. Basically, if SP configuration has
>>> marked any claim as mandatory, we consider that service provider cannot be
>>> used without that attribute. Therefore user needs to share that value with
>>> that particular SP
>>>

 Thanks,
 Jochen

 Harsha Thirimanna  schrieb am Mi. 2. Nov. 2016 um
 06:19:

> After , the use get authenticated and try to login to same sp by using
> different tab also we may have to prompt the input screen because there 
> may
> be additional claims will be added around this. So in that case even 
> though
> the sequence config is completed, do we call the
> *handlePostAuthentication**() *method implementation ? Because is saw
> there is if condition to check that competed or not within
> *handlePostAuthentication**() *method ?
>
> On Nov 2, 2016 12:07 AM, "Johann Nallathamby"  wrote:
>
>
>
> On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana 
> wrote:
>
>
>
> On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna  > wrote:
>
> Hi,
>
> On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby 
> wrote:
>
>
>
> On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <
> darsh...@wso2.com> wrote:
>
> For federated users, it's ok to prompt missing attributes every time
> (unless they are associated and assert with a local user). I think we
> sho

Re: [Architecture] C5 User Management APIs with SCIM 2.0

[Gayan Gunawardana]

Hi All,

Thanks for suggestions.

On Mon, Jan 23, 2017 at 5:14 PM, Isura Karunaratne  wrote:

> Hi Ishara, Gayan,
>
> On Mon, Jan 23, 2017 at 9:46 AM, Ishara Karunarathna 
> wrote:
>
>> Hi,
>>
>> In C5 already we have SCIM 2.0 for User and Group management (This is the
>> only user management REST API we provide) and not using SOAP base services
>> anymore.
>>
>> And for identity management also we are going to have REST API but not
>> SCIM based APIs.
>> So +1 for Gayans idea to use SCIM based API for those as well.
>>
>
> In IS 5.3.0 we implemented rest APIs for Identity Management features like
> Password Recovery and Self Registration. What are the advantages of using
> SCIM APIs to support Identity Mangement functionalites ?
>
> Thanks
> Isura.
>
>>
>> We can implement this in two steps.
>> 1. Convert these identity management APIs to use the SCIM request
>> response format.
>> 2. Implement as SCIM extensions.
>>
>> So +1 to start with the step 1 and later go with 2
>> Thanks,
>> Ishara
>>
>> On Mon, Jan 23, 2017 at 8:40 AM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 23, 2017 at 12:02 AM, Gayan Gunawardana 
>>> wrote:
>>>
 Attaching missing images.



 ​
 ​

 On Sun, Jan 22, 2017 at 11:49 PM, Gayan Gunawardana 
 wrote:

> SCIM Overview and Concept
> SCIM stands for “Simplified Cloud Identity Management” and later it
> has been changed to “System for Cross-domain Identity Management”.  SCIM
> was originally developed for Cloud services, but according to later
> understanding decided that it was not bounded to Cloud and can be used
> purely on-premise scenarios as well. New name reflects above idea.
>
> Originally SCIM was developed with three main actors.
>
>-
>
>CSP: Cloud Service Provider
>-
>
>   A CSP is the entity which is holding identities of end users
>   and also provide services for user management.
>   -
>
>ECS: Enterprise Cloud Subscriber
>-
>
>   The ECS Actor is a single entity which is given administrative
>   responsibility to manage other identity accounts.
>   -
>
>CSU: Cloud Service User
>-
>
>   A CSU represents the real cloud service end user.
>
>
> WSO2 Identity Server as a SCIM Provider
> According to new definition of SCIM (Sysem for Cross-domain Identity
> Management) WSO2 Identity Server also can act as SCIM provider which is
> similar to Cloud Service Provider.
>
>
>
>
>-
>
>WSO2 Identity Server
>-
>
>   Similar to Cloud Service Provider. Provide services to manage
>   end user identities.
>   -
>
>Authorized Entity for Provisioning
>-
>
>   Similar to  Enterprise Cloud Subscriber. Authorized Entity will
>   be single identity who has administrative privilege to manage end 
> user
>   accounts.
>   -
>
>End User
>- Similar to Cloud Service User.
>
>
> How we have done things on C4
> In C4 Up to Identity Server 5.3.0 we have been using SCIM only for
> provisioning users from external system to Identity Server (Inbound
> Provisioning). Also In C4 we have couple of SOAP services to manage user
> identities.
>
> UserAdmin: Used for Management Console user management operations.
>
> RemoteUserStoreManagerService:  Manage user identities in user store
> remotely.
>
> UserInformationRecoveryService:  Self signup, Username recovery,
> Password recovery
>
> Even though above services have been implemented for different
> objectives there are lot of duplicate efforts. For an example add user
> operation is included in all three services. Sometimes when you switch
> among different services for same functionality for an example
> UserInformationRecoveryService → registerUser to SCIM add user operation 
> or
> UserAdmin add user operation you may find different data formats and
> performance issues due to different implementations.
>
>
> What is new for C5 ?
> What we are proposing new is reuse standard SCIM APIs for all user
> management functionalities.  Since SCIM 2.0 provide more comprehensive 
> user
> management functionalities we can build common layer to serve all user
> management use cases for different channels. Basically User Admin can
> manage other identity accounts via SCIM APIs without having separate
> implementation.
>

>>> Handling users/groups is an important aspect of IS and we should expose
>>> these capabilities as a product API too, when industry adopted standard
>>> present we should not define our own APIs hence +1 to use SCIM.
>>>
>>>

> Further we can extend the usage of SCIM for identity management
> functionalit

Re: [Architecture] [Dev] Username Recovery Feature in IS 6.0.0

[Shani Ranasinghe]

On Sat, Jan 21, 2017 at 8:20 PM, Imesh Chandrasiri  wrote:

> Hi,
>
> +1 for having a recovery option selection such as Facebook does. In any
> case where user no longer have access to his/her email address, selecting a
> secondary option would be beneficial.
>
> On Sat, Jan 21, 2017 at 6:10 PM, Pubudu Gunatilaka 
> wrote:
>
>> Hi,
>>
>> What is the possibility of selecting a recovery option such as email or
>> mobile?
>>
>> When a user is matched to the given information, what if we provide
>> possible recovery options such as sending details to the email address or
>> to the mobile number which is already given?
>>
> +1, we could also consider using the security questions/ or verifying the
mobile number registered with the account, if the above is not available
like google does.

>
>> Thank you!
>>
>> On Sat, Jan 21, 2017 at 4:20 PM, Pushpalanka Jayawardhana > > wrote:
>>
>>> Hi All,
>>>
>>> On Sat, Jan 21, 2017 at 1:35 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Dinali,

 On Sat, Jan 21, 2017 at 12:33 PM, Dinali Dabarera 
 wrote:

> Hi all,
>
> We are working on implementing username recovery feature for IS 6.0.0
>
> *The admin has to enable the Username Recovery*
>
>
> *When Username Recovery enabled:*
>
>- User portal user can click on the forget username option.
>- The User can enter his details of the default profile.
>- The System will match the entered details with the claims
>available and if they matched, the relevant username will email to his
>email address and prompt a notification saying that an email is sent 
> to his
>mail.
>- If it doesn't match, the user will notify telling that relevant
>user is not registered in the system.
>
> We need to inform user, if multiple users matching to the given
 criteria. Then the user can fiill additional details to recover username.

>>> We should have a mechanism like captcha verification here, to avoid
>>> possible brute force attack.
>>>


> *When Username Recovery is disabled:*
>
>- User portal user may not be able to recover his username.
>- The User needs to contact the admin of the system to recover his
>username.
>
> The admin enables the username recovery in the identity.yaml file for
> the users in the domain.  Since we have different user stores available in
> IS 6.0.0,
>   *Does the admin need to enable username recovery in user store
> wise or Does he need to configure it for the whole domain at once?*
>
>
 We need to have a global configuration identity.yaml file for all the
 domains. It is better to have domain/roles/group wise configuration for all
 the identity managment scenarios like account lock, password policy,
 password recovery, idle account suspenstion, force password reset, user
 onbording with ask paassword.


 Thanks
 Isura.

>
> Please provide us your comments on this point.
>
> Thanks,
>
> Dina.
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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


>>>
>>> Thanks,
>>> --
>>> Pushpalanka.
>>> --
>>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
>>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
>>> Mobile: +94779716248
>>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p
>>> ushpalanka/ | Twitter: @pushpalanka
>>>
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Thanks and Best Regards,*
> Imesh Ashandimal Chandrasiri
> *Software Engineer*
> WSO2, Inc.
> lean . enterprise . middleware
> *E:* ime...@wso2.com | *P:* 0716519187
>
>
> Disclaimer: This communication may contain privileged or other
> confidential information and is intended exclusively for the ad

Re: [Architecture] [IS 6.0.0] Email Management Component Implementation

[Ayesha Dissanayaka]

On Tue, Jan 24, 2017 at 10:39 AM, Ishara Karunarathna 
wrote:

> Shall we create a template folder inside configs and put relevant configs
> there
>
> config/
> └── templates/
>   └── email/
>

+1


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

20, Palmgrove Avenue, Colombo 3
E-Mail: aye...@wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS 6.0.0] Email Management Component Implementation

[Ishara Karunarathna]

Hi All,

On Tue, Jan 24, 2017 at 10:28 AM, Ayesha Dissanayaka 
wrote:

> Hi,
>
> The following directory structure will be used to keep the template based
>>> on the locale.
>>>
>>> config/
>>> └── email/
>>> ├── en_US
>>> │└── email-admin-config.yaml
>>> └── en_GB
>>> └── email-admin-config.yaml
>>>
>>>
>> Currently the structure we have is,
>>
>> config/
>> └── email/
>> ├── scenario1 (like AccountRecovery)
>>
>>  └── en_US (here we have the actual template)
>>
>>  └── en_GB
>>
>>
> As we discussed offline, I suggest that we group email templates based on
> locale and having a template per scenario.
>
> config/
> └── email/
> ├── en_US (locale)
> |   └── password-recovery.yaml (here we have the actual template in 
> en_US) (template per scenario)
> |   └── email-confirmation.yaml (here we have the actual template in 
> en_US)
> |   └── ...
>
> ├── fr
> └── password-recovery.yaml (here we have the actual template in 
> fr)
> └── email-confirmation.yaml (here we have the actual template in 
> fr)
> └── ...
>
>
These are templates rather configurations, and we may have some other
templates too link redirection pages etc.
Shall we create a template folder inside configs and put relevant configs
there

config/
└── templates/
  └── email/
-Ishara

>
> If we put all the email templates in one template file, then it becomes
> hard to maintain as this file may grow as new email templates are
> introduces. Also the content of a particular template (ex: html templates)
> will also become hard to maintain in one file. With above suggested
> separation, CRUD operations for a particular template of a locale become
> simple, as those will be file based configurations going forward.
>
> --
> *Ayesha Dissanayaka*
> Software Engineer,
> WSO2, Inc : http://wso2.com
> 
> 20, Palmgrove Avenue, Colombo 3
> E-Mail: aye...@wso2.com 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Ishara Karunarathna
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS 6.0.0] Email Management Component Implementation

[Ayesha Dissanayaka]

Hi,

The following directory structure will be used to keep the template based
>> on the locale.
>>
>> config/
>> └── email/
>> ├── en_US
>> │└── email-admin-config.yaml
>> └── en_GB
>> └── email-admin-config.yaml
>>
>>
> Currently the structure we have is,
>
> config/
> └── email/
> ├── scenario1 (like AccountRecovery)
>
>  └── en_US (here we have the actual template)
>
>  └── en_GB
>
>
As we discussed offline, I suggest that we group email templates based on
locale and having a template per scenario.

config/
└── email/
├── en_US (locale)
|   └── password-recovery.yaml (here we have the actual
template in en_US) (template per scenario)
|   └── email-confirmation.yaml (here we have the actual
template in en_US)
|   └── ...

├── fr
└── password-recovery.yaml (here we have the actual template in fr)
└── email-confirmation.yaml (here we have the actual template in fr)
└── ...


If we put all the email templates in one template file, then it becomes
hard to maintain as this file may grow as new email templates are
introduces. Also the content of a particular template (ex: html templates)
will also become hard to maintain in one file. With above suggested
separation, CRUD operations for a particular template of a locale become
simple, as those will be file based configurations going forward.

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

20, Palmgrove Avenue, Colombo 3
E-Mail: aye...@wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][APIM] Full Text Search

[Rajith Roshan]

Hi Malith,

Thanks for your input. I have changed the jmeter scripts according to you
instructions.
I was using a oracle docker instance in my local machine. I have changed it
to a remote oracle database. Now the latency is much less. I will share all
the performance numbers once I have finished collecting them for oracle,
mssql, mysql and postgres databases.

Thanks!
Rajith

On Tue, Jan 24, 2017 at 9:46 AM, Malith Jayasinghe  wrote:

> @Rajith
>
> As per the offline discussion we had regarding the performance evaluation
> (using JMETER) of the two methods:
> - use 2 separate thread groups for evaluating the performance of 2 DB
> based search methods
> - run each thread group sequentially
> - run the test for a longer period under different concurrency level and
> record the latency and TPS
>
> With regard to the long latencies you are noticing, we need to figure out
> if this is related to the database query/queries or something else. To do a
> quick test: simply log the execution time of the query/queries. If the
> execution times are high (or have spikes) then we can try to optimize the
> DB query. Otherwise we have to do some further investigations.
>
> Thanks
>
> Malith
>
>
>
>
>
>
> On Sat, Jan 14, 2017 at 10:43 PM, Nuwan Dias  wrote:
>
>> File system based indexers bring new challenges in the container world.
>> It also poses challenges in HA (multinode) and multi regional deployments.
>> Therefore if we're selecting a solr indexing approach, the only practical
>> solution is to go with a solr server based architecture.
>>
>> Even with a solr server assisted architecture, we still have complexities
>> when dealing with multi regional deployments. Also since API artifacts
>> reside in the database, if we're loading search results from an index, we
>> have to sync the permissions of the artifacts in the index too. Plus this
>> makes the deployment complex.
>>
>> Given the complexities that have to be addressed in an indexing solution,
>> I'd prefer to opt with the DB based search at least to start off with.
>> Since APIs and their permissions are both maintained in the DB, it would be
>> much simple if the search also works on that. Unlike in C4 this database
>> will only have data of 1 tenant. Hence we're not expecting the API count to
>> be in the thousands. Therefore I think searching through the database
>> should be feasible.
>>
>> Thanks,
>> NuwanD.
>>
>> On Sat, 14 Jan 2017 at 8:27 am, Chandana Napagoda 
>> wrote:
>>
>>> Hi Rajith,
>>>
>>> I believe indexing based approach is more suitable for any search
>>> solution because its design is to support fast search results. If you use
>>> database search, you have to use multiple DB indexes to improve search
>>> performance, and that will reduce the performance of insert operations.
>>>
>>> I think, REG_LOG kind of history table is not necessary for APIM
>>> product, since it is totally aware of the APIM artifacts(APIs, Docs, forum
>>> posts) and you can directly connect to the DB[1] from the text search
>>> engine and index the resources. As per the Solr documentation, it is
>>> capable of importing only the new additions(delta) for indexing.
>>>
>>> [1]. https://cwiki.apache.org/confluence/display/solr/Uploading+
>>> Structured+Data+Store+Data+with+the+Data+Import+Handler
>>>
>>> Regards,
>>> Chandana
>>>
>>>
>>> On Fri, Jan 13, 2017 at 11:44 AM, Rajith Roshan 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> We are currently evaluating how to perform full text search at the
>>> database level for C5 based API Manager. We will be evaluating this for
>>> different types of databases to find their implementation complexities and
>>> limitations.
>>> Other option available for us to use indexing based approach (use Solr)
>>>
>>> *Database full text search *
>>> *Pros*
>>>
>>>- Less complications when using container based approach
>>>- Clustering will require only database syncing.
>>>- No need to maintain and ship external search engine.
>>>
>>> *Cons*
>>>
>>>- Implementation may vary significantly based on the database type
>>>- There can be limitation in full text search for particular
>>>database types (For ex: mysql full text support only prefix search)
>>>- Queries will differ based on database type
>>>- Document search will not be available, because they are stored as
>>>blobs
>>>
>>>
>>> *Indexing based approach *
>>> *Pros*
>>>
>>>- Document search
>>>- Search will be efficient (No need to access database)
>>>
>>> *Cons*
>>>
>>>- Since indexing data is written to file system , when going for
>>>container based approach we would require mechanisms to file system 
>>> mounting
>>>- Syncing indexers in a cluster would require something similar to
>>>existing C4 based registry architecture (use of REG_LOG table)
>>>- Maintaining (for ex: Version updates) and shipping external search
>>>engine.
>>>
>>> Your valuable input regrading this is highly appreciated.
>>>
>>> Thanks!
>>> Rajith
>>>
>>

Re: [Architecture] [C5][APIM] Full Text Search

[Malith Jayasinghe]

@Rajith

As per the offline discussion we had regarding the performance evaluation
(using JMETER) of the two methods:
- use 2 separate thread groups for evaluating the performance of 2 DB based
search methods
- run each thread group sequentially
- run the test for a longer period under different concurrency level and
record the latency and TPS

With regard to the long latencies you are noticing, we need to figure out
if this is related to the database query/queries or something else. To do a
quick test: simply log the execution time of the query/queries. If the
execution times are high (or have spikes) then we can try to optimize the
DB query. Otherwise we have to do some further investigations.

Thanks

Malith






On Sat, Jan 14, 2017 at 10:43 PM, Nuwan Dias  wrote:

> File system based indexers bring new challenges in the container world. It
> also poses challenges in HA (multinode) and multi regional deployments.
> Therefore if we're selecting a solr indexing approach, the only practical
> solution is to go with a solr server based architecture.
>
> Even with a solr server assisted architecture, we still have complexities
> when dealing with multi regional deployments. Also since API artifacts
> reside in the database, if we're loading search results from an index, we
> have to sync the permissions of the artifacts in the index too. Plus this
> makes the deployment complex.
>
> Given the complexities that have to be addressed in an indexing solution,
> I'd prefer to opt with the DB based search at least to start off with.
> Since APIs and their permissions are both maintained in the DB, it would be
> much simple if the search also works on that. Unlike in C4 this database
> will only have data of 1 tenant. Hence we're not expecting the API count to
> be in the thousands. Therefore I think searching through the database
> should be feasible.
>
> Thanks,
> NuwanD.
>
> On Sat, 14 Jan 2017 at 8:27 am, Chandana Napagoda 
> wrote:
>
>> Hi Rajith,
>>
>> I believe indexing based approach is more suitable for any search
>> solution because its design is to support fast search results. If you use
>> database search, you have to use multiple DB indexes to improve search
>> performance, and that will reduce the performance of insert operations.
>>
>> I think, REG_LOG kind of history table is not necessary for APIM product,
>> since it is totally aware of the APIM artifacts(APIs, Docs, forum posts)
>> and you can directly connect to the DB[1] from the text search engine and
>> index the resources. As per the Solr documentation, it is capable of
>> importing only the new additions(delta) for indexing.
>>
>> [1]. https://cwiki.apache.org/confluence/display/solr/
>> Uploading+Structured+Data+Store+Data+with+the+Data+Import+Handler
>>
>> Regards,
>> Chandana
>>
>>
>> On Fri, Jan 13, 2017 at 11:44 AM, Rajith Roshan  wrote:
>>
>> Hi all,
>>
>> We are currently evaluating how to perform full text search at the
>> database level for C5 based API Manager. We will be evaluating this for
>> different types of databases to find their implementation complexities and
>> limitations.
>> Other option available for us to use indexing based approach (use Solr)
>>
>> *Database full text search *
>> *Pros*
>>
>>- Less complications when using container based approach
>>- Clustering will require only database syncing.
>>- No need to maintain and ship external search engine.
>>
>> *Cons*
>>
>>- Implementation may vary significantly based on the database type
>>- There can be limitation in full text search for particular database
>>types (For ex: mysql full text support only prefix search)
>>- Queries will differ based on database type
>>- Document search will not be available, because they are stored as
>>blobs
>>
>>
>> *Indexing based approach *
>> *Pros*
>>
>>- Document search
>>- Search will be efficient (No need to access database)
>>
>> *Cons*
>>
>>- Since indexing data is written to file system , when going for
>>container based approach we would require mechanisms to file system 
>> mounting
>>- Syncing indexers in a cluster would require something similar to
>>existing C4 based registry architecture (use of REG_LOG table)
>>- Maintaining (for ex: Version updates) and shipping external search
>>engine.
>>
>> Your valuable input regrading this is highly appreciated.
>>
>> Thanks!
>> Rajith
>>
>> --
>> Rajith Roshan
>> Software Engineer, WSO2 Inc.
>>
>>
>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Chandana Napagoda*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.org
>>
>> *Email  :  chand...@wso2.com **Mobile : +94718169299
>> <+94%2071%20816%209299>*
>>
>> *Blog  :http://cnapagoda.blogspot.com 
>> | http://chandana.napagoda.com *
>>
>> *Linkedin : http://www.linkedin.com/in/chandananapagoda
>> *
>>
>>
>>
>>
> _

Re: [Architecture] WebSocket support for MSF4J

[Sagara Gunathunga]

On Thu, Jan 19, 2017 at 10:54 AM, Irunika Weeraratne 
wrote:

> Hi Lakshman,
> On Wed, Jan 18, 2017 at 2:57 PM, Lakshman Udayakantha 
> wrote:
>
>> I think you don't have to specially implement authentication mechanism
>> for web socket protocol. According to the spec[1], websocket doesn't
>> provide a way to authenticate clients. You can use any other mechanism with
>> HTTPS or HTTP etc. to authenticate the server.
>>
>> This protocol doesn't prescribe any particular way that servers can 
>> authenticate clients during the WebSocket handshake.  The WebSocket server 
>> can use any client authentication mechanism available to a generic HTTP 
>> server,
>>
>> such as cookies, HTTP authentication, or TLS authentication.
>>
>>
>>  [1] https://tools.ietf.org/html/rfc6455
>>
>
> Yes. They are not providing a mechanism and I'm trying to reuse the
> existing authentication mechanisms for Microservices in MSF4J.
> Most probably it will work since there is no any difference between a HTTP
> request and WebSocket Upgrade Request. Now I'm working on it.
>

Java API for WS spec does not define any specific security mechanisms
instead it recommend to reuse Web container security model and HTTP
security for authentication,  please refer following 2 posts[1][2] based on
Tyrus.

[1] - http://ssagara.blogspot.com/2014/07/websocket-security-patterns.html
[2] -
http://ssagara.blogspot.com/2014/08/secure-java-websocket-endpoints.html

Thanks !

>
> Thanks,
> Irunika
> *Irunika Weeraratne*
> *Software Engineer | WSO2, Inc. *
> *Email : irun...@wso2.com *
> *LinkedIn : https://lk.linkedin.com/in/irunika
> *
> *Mobile : +94712403314 <+94%2071%20240%203314>*
> *Lean . Enterprise . Middleware*
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Enterprise Integrator 6.0.0 Milestone 1 Released !

[Madhawa Gunasekara]

The WSO2 Integration team is pleased to announce the 1st Milestone release
of WSO2 Enterprise Integrator (EI)  6.0.0.

Source & binary distribution files of WSO2 Enterprise Integrator 6.0.0

Distribution : https://github.com/wso2/product-ei/releases/tag/v6.0.0-m1
Known Issues : https://github.com/wso2/product-ei/issues

Thanks,
~Integration Team~
--
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release WSO2 IoT Server 3.0.0 RC2

[Rasika Perera]

Hi All,

Thanks for testing WSO2 IoT Server 3.0.0-RC2. This vote passed with 17 +1s
and 0 -1s.
We will proceed with WSO2 IoT Server 3.0.0 release.

Thanks,
Rasika

On Mon, Jan 23, 2017 at 10:00 AM, Maninda Edirisooriya 
wrote:

> Hi,
>
> I have tested
>
>  - Security vulnerability analysis with OWASP
>  - Static code analysis for security issues with FindBugs security plugin
>  - User creation
>  - Role creation and assignment
>  - Adding users to groups, removing users from groups
>  - Setting / removing permissions to roles
>  - Visibility of devices for different users with permission changes
>  - Enrolling multiple devices with different permissions
>
> [+] Stable - go ahead and release.
>
> Thanks.
>
>
> *Maninda Edirisooriya*
> Senior Software Engineer
>
> *WSO2, Inc.*lean.enterprise.middleware.
>
> *Blog* : http://maninda.blogspot.com/
> *E-mail* : mani...@wso2.com
> *Skype* : @manindae
> *Twitter* : @maninda
>
> On Fri, Jan 20, 2017 at 10:33 PM, Rasika Perera  wrote:
>
>> [-architecture, -dev]
>>
>> Guys,
>>
>> Please vote on your tested areas.
>>
>> Thanks,
>> Rasika
>>
>> On Fri, Jan 20, 2017 at 10:29 PM, Rasika Perera  wrote:
>>
>>> Hi Devs,
>>>
>>> *WSO2 ​IoT ​Server ​3.0.0-RC2 Released*
>>>
>>> This is the 2nd Release Candidate of the WSO2
>>> ​IoT Server​
>>>
>>> ​3​
>>> .0.0
>>>
>>> Please download, test the product and vote.
>>>
>>> *​*Known issues  :
>>>  https://wso2.org/jira/issues/?filter=13634
>>> Fixes provided :​
>>> https://wso2.org/jira/issues/?filter=13635
>>>
>>> *Source and binary distribution files:*
>>> https://github.com/wso2/product-iots/releases/tag/v3.0.0-RC2
>>>
>>> *The tag to be voted upon:*
>>> https://github.com/wso2/product-iots/tree/v3.0.0-RC2
>>>
>>> Please vote as follows.
>>> [+] Stable - go ahead and release
>>> [-] Broken - do not release (explain why)
>>>
>>> Thanks,
>>> ~WSO2 IoT Team~
>>>
>>> --
>>> With Regards,
>>>
>>> *Rasika Perera*
>>> Software Engineer
>>> LinkedIn: http://lk.linkedin.com/in/rasika90
>>>
>>> 
>>>
>>> WSO2 Inc. www.wso2.com
>>> lean.enterprise.middleware
>>>
>>
>>
>>
>> --
>> With Regards,
>>
>> *Rasika Perera*
>> Software Engineer
>> LinkedIn: http://lk.linkedin.com/in/rasika90
>>
>> 
>>
>> WSO2 Inc. www.wso2.com
>> lean.enterprise.middleware
>>
>
>


-- 
With Regards,

*Rasika Perera*
Software Engineer
LinkedIn: http://lk.linkedin.com/in/rasika90



WSO2 Inc. www.wso2.com
lean.enterprise.middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

[Nuwandi Wickramasinghe]

Hi Asela,

This does not work in 5.3.0.

IS will pop up for the mandatory claims requested by the Service Provider
if they are not sent by the federated authenticator. But the claims
provided by the user at this step are not persisted for federated users,
 even if they are provisioned to IS. I think we have missed that part and
better to persist these values in provisioned user profile.

However, the mandatory claim configuration in Service Provider indicates
this claim is mandatory to access that particular SP. Should we have a
different configuration to define mandatory claims for provisioning ?

thanks
Nuwandi

On Mon, Jan 23, 2017 at 6:41 PM, Asela Pathberiya  wrote:

> Hi Nuwandi
>
> Can WSO2IS popup for user claims which must be provision in to the local
> user store (JIT provisioning) ?
>
> If federated claims are not enough to update the user store, then it is
> assume that WSO2IS can popup for addition claims & persisted.. Does it work
> with WSO2IS 5.3.0 ?
>
> Thanks,
> Asela.
>
> On Sat, Jan 14, 2017 at 11:37 PM, Nuwandi Wickramasinghe <
> nuwan...@wso2.com> wrote:
>
>> Sorry for the late reply. Please find the inline comments.
>>
>> thanks and regards.
>>
>> On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker <
>> jochen.traunec...@googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> Is the user considered as successfully authenticated even if he will
>>> never provide the asked claims? What will be send back to SP if user is NOT
>>> providing any claims?
>>>
>> No. User will not be authenticated and he will not be able access service
>> provider. But the user will be asked to provide the claims only if they are
>> marked as "Mandatory" in the SP configuration in Identity Server. You can
>> add requested claims in SP configuration without marking them as mandatory.
>> In that case IS will authenticate user and send those requested claims to
>> the SP if they are available in user profile.
>>
>> There is the scenario with WebSSO and SP1 asking for claims SP2 is not
>>> interested in. While establishing the very first authentication session for
>>> user X with SP1, that user X might be successfully authenticated but will
>>> not share additional claims. Assuming some DENY response will be send back
>>> to SP1 and user moves forward to SP2, will he then be considered as already
>>> successfully authenticated ?
>>>
>> As per the current implementation, if SP1 configuration has any mandatory
>> claims, user will not be authenticated until he provides them. User will
>> have to login in to SP2
>>
>>>
>>> Besides the "provide more claims" step we can expect a "confirm to share
>>> claims with SP-X" become a requirement, too. This could get handled in the
>>> handlePostAuthentication() method, too, but then expectation is that
>>> although a DENY is send to SP-1 (when user doesn't want to share
>>> information) the user is considered successfully authenticated in IdP (IS)
>>> with e.g. SP-2 he already confirmed before 
>>>
>> We do not have this implemented. Basically, if SP configuration has
>> marked any claim as mandatory, we consider that service provider cannot be
>> used without that attribute. Therefore user needs to share that value with
>> that particular SP
>>
>>>
>>> Thanks,
>>> Jochen
>>>
>>> Harsha Thirimanna  schrieb am Mi. 2. Nov. 2016 um
>>> 06:19:
>>>
 After , the use get authenticated and try to login to same sp by using
 different tab also we may have to prompt the input screen because there may
 be additional claims will be added around this. So in that case even though
 the sequence config is completed, do we call the
 *handlePostAuthentication**() *method implementation ? Because is saw
 there is if condition to check that competed or not within
 *handlePostAuthentication**() *method ?

 On Nov 2, 2016 12:07 AM, "Johann Nallathamby"  wrote:



 On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana 
 wrote:



 On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna 
 wrote:

 Hi,

 On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby 
 wrote:



 On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <
 darsh...@wso2.com> wrote:

 For federated users, it's ok to prompt missing attributes every time
 (unless they are associated and assert with a local user). I think we
 should display a message like [1].


 I don't know if the message in [1] will always be suitable, but since
 we can customize this message it should be fine. Because it really depends
 on the configurations admin has made in the IDP side also. So if
 configurations are correct then user can fill his profile in the federated
 IDP side and avoid filling attributes in IS.



 What happens when we try federated login that associated with local
 user and also assert with local user? Does that work without changing
 current implementation?

 And gi

Re: [Architecture] [IS 6.0.0] Email Management Component Implementation

[Farasath Ahamed]

On Sun, Jan 22, 2017 at 3:10 AM, Lahiru Manohara  wrote:

> Hi,
>
> We are implementing email management component for IS 6.0.0. The following
> properties will be included in the email template.
>
> configuration:
>  -
>   subject:
>   body:
>   footer:
>   type:
>   display:
>   locale:
>   emailContentType:
>
> The following directory structure will be used to keep the template based
> on the locale.
>
> config/
> └── email/
> ├── en_US
> │└── email-admin-config.yaml
> └── en_GB
> └── email-admin-config.yaml
>
>
Currently the structure we have is,

config/
└── email/
├── scenario1 (like AccountRecovery)

 └── en_US (here we have the actual template)

 └── en_GB


With this structure it was easy to delete a template type easily,
Let's say you wanted to delete all AccountRecovery template types, you
simply delete the "scenario1" template folder.

But with the proposed structure this becomes a bit tricky IMO, you
need to iterate through all locales (folders) and then read the
email-admin-config.yaml and delete the specific type of templates.


Even if you want to delete say AccountRecovery template in en_US you
would have to read the email-admin-config.yaml and then delete the
specific template and save the file again.


Any specifc reasons for chosing this directory structure?




> Appreciate your suggestions on above design.
>
> Best Regards,
> --
> *Lahiru Manohara*
> *Software Engineer*
> Mobile: +94716561576
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>
> ___
> 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] Identity Server 5.3.0 New Feature - Prompt for missing predefined user attributes in the authentication flow

[Asela Pathberiya]

Hi Nuwandi

Can WSO2IS popup for user claims which must be provision in to the local
user store (JIT provisioning) ?

If federated claims are not enough to update the user store, then it is
assume that WSO2IS can popup for addition claims & persisted.. Does it work
with WSO2IS 5.3.0 ?

Thanks,
Asela.

On Sat, Jan 14, 2017 at 11:37 PM, Nuwandi Wickramasinghe 
wrote:

> Sorry for the late reply. Please find the inline comments.
>
> thanks and regards.
>
> On Thu, Nov 17, 2016 at 10:05 PM, Jochen Traunecker <
> jochen.traunec...@googlemail.com> wrote:
>
>> Hi,
>>
>> Is the user considered as successfully authenticated even if he will
>> never provide the asked claims? What will be send back to SP if user is NOT
>> providing any claims?
>>
> No. User will not be authenticated and he will not be able access service
> provider. But the user will be asked to provide the claims only if they are
> marked as "Mandatory" in the SP configuration in Identity Server. You can
> add requested claims in SP configuration without marking them as mandatory.
> In that case IS will authenticate user and send those requested claims to
> the SP if they are available in user profile.
>
> There is the scenario with WebSSO and SP1 asking for claims SP2 is not
>> interested in. While establishing the very first authentication session for
>> user X with SP1, that user X might be successfully authenticated but will
>> not share additional claims. Assuming some DENY response will be send back
>> to SP1 and user moves forward to SP2, will he then be considered as already
>> successfully authenticated ?
>>
> As per the current implementation, if SP1 configuration has any mandatory
> claims, user will not be authenticated until he provides them. User will
> have to login in to SP2
>
>>
>> Besides the "provide more claims" step we can expect a "confirm to share
>> claims with SP-X" become a requirement, too. This could get handled in the
>> handlePostAuthentication() method, too, but then expectation is that
>> although a DENY is send to SP-1 (when user doesn't want to share
>> information) the user is considered successfully authenticated in IdP (IS)
>> with e.g. SP-2 he already confirmed before 
>>
> We do not have this implemented. Basically, if SP configuration has marked
> any claim as mandatory, we consider that service provider cannot be used
> without that attribute. Therefore user needs to share that value with that
> particular SP
>
>>
>> Thanks,
>> Jochen
>>
>> Harsha Thirimanna  schrieb am Mi. 2. Nov. 2016 um
>> 06:19:
>>
>>> After , the use get authenticated and try to login to same sp by using
>>> different tab also we may have to prompt the input screen because there may
>>> be additional claims will be added around this. So in that case even though
>>> the sequence config is completed, do we call the
>>> *handlePostAuthentication**() *method implementation ? Because is saw
>>> there is if condition to check that competed or not within
>>> *handlePostAuthentication**() *method ?
>>>
>>> On Nov 2, 2016 12:07 AM, "Johann Nallathamby"  wrote:
>>>
>>>
>>>
>>> On Tue, Nov 1, 2016 at 11:30 PM, Gayan Gunawardana 
>>> wrote:
>>>
>>>
>>>
>>> On Tue, Nov 1, 2016 at 10:07 AM, Ishara Karunarathna 
>>> wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Nov 1, 2016 at 12:37 AM, Johann Nallathamby 
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana >> > wrote:
>>>
>>> For federated users, it's ok to prompt missing attributes every time
>>> (unless they are associated and assert with a local user). I think we
>>> should display a message like [1].
>>>
>>>
>>> I don't know if the message in [1] will always be suitable, but since we
>>> can customize this message it should be fine. Because it really depends on
>>> the configurations admin has made in the IDP side also. So if
>>> configurations are correct then user can fill his profile in the federated
>>> IDP side and avoid filling attributes in IS.
>>>
>>>
>>>
>>> What happens when we try federated login that associated with local user
>>> and also assert with local user? Does that work without changing current
>>> implementation?
>>>
>>> And giving the option to associate user during the JIT provioning is an
>>> addional capability which also requested by many. We would need to done as
>>> a improvement for JIT provioning. For the perspective of this feature, if
>>> it works with manually associated (and locally asserted users), it would
>>> also work automatically associated users.
>>>
>>>
>>> So are we going to automatically associate JIT provisioned users?
>>> Otherwise each time it will request for attributes from user as I
>>> understand.
>>>
>>>
>>>
>>> [1] "You are trying login to application x, but it need following
>>> information filled in the user profile. You can fill those below and
>>> proceed with the authentication. But it's adviced to fill this information
>>> in your y-IdP profile in order to avoid this step every time you login."
>>>
>>> Thanks,
>>>
>>>

Re: [Architecture] C5 User Management APIs with SCIM 2.0

[Isura Karunaratne]

Hi Ishara, Gayan,

On Mon, Jan 23, 2017 at 9:46 AM, Ishara Karunarathna 
wrote:

> Hi,
>
> In C5 already we have SCIM 2.0 for User and Group management (This is the
> only user management REST API we provide) and not using SOAP base services
> anymore.
>
> And for identity management also we are going to have REST API but not
> SCIM based APIs.
> So +1 for Gayans idea to use SCIM based API for those as well.
>

In IS 5.3.0 we implemented rest APIs for Identity Management features like
Password Recovery and Self Registration. What are the advantages of using
SCIM APIs to support Identity Mangement functionalites ?

Thanks
Isura.

>
> We can implement this in two steps.
> 1. Convert these identity management APIs to use the SCIM request response
> format.
> 2. Implement as SCIM extensions.
>
> So +1 to start with the step 1 and later go with 2
> Thanks,
> Ishara
>
> On Mon, Jan 23, 2017 at 8:40 AM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Mon, Jan 23, 2017 at 12:02 AM, Gayan Gunawardana 
>> wrote:
>>
>>> Attaching missing images.
>>>
>>>
>>>
>>> ​
>>> ​
>>>
>>> On Sun, Jan 22, 2017 at 11:49 PM, Gayan Gunawardana 
>>> wrote:
>>>
 SCIM Overview and Concept
 SCIM stands for “Simplified Cloud Identity Management” and later it has
 been changed to “System for Cross-domain Identity Management”.  SCIM was
 originally developed for Cloud services, but according to later
 understanding decided that it was not bounded to Cloud and can be used
 purely on-premise scenarios as well. New name reflects above idea.

 Originally SCIM was developed with three main actors.

-

CSP: Cloud Service Provider
-

   A CSP is the entity which is holding identities of end users and
   also provide services for user management.
   -

ECS: Enterprise Cloud Subscriber
-

   The ECS Actor is a single entity which is given administrative
   responsibility to manage other identity accounts.
   -

CSU: Cloud Service User
-

   A CSU represents the real cloud service end user.


 WSO2 Identity Server as a SCIM Provider
 According to new definition of SCIM (Sysem for Cross-domain Identity
 Management) WSO2 Identity Server also can act as SCIM provider which is
 similar to Cloud Service Provider.




-

WSO2 Identity Server
-

   Similar to Cloud Service Provider. Provide services to manage
   end user identities.
   -

Authorized Entity for Provisioning
-

   Similar to  Enterprise Cloud Subscriber. Authorized Entity will
   be single identity who has administrative privilege to manage end 
 user
   accounts.
   -

End User
- Similar to Cloud Service User.


 How we have done things on C4
 In C4 Up to Identity Server 5.3.0 we have been using SCIM only for
 provisioning users from external system to Identity Server (Inbound
 Provisioning). Also In C4 we have couple of SOAP services to manage user
 identities.

 UserAdmin: Used for Management Console user management operations.

 RemoteUserStoreManagerService:  Manage user identities in user store
 remotely.

 UserInformationRecoveryService:  Self signup, Username recovery,
 Password recovery

 Even though above services have been implemented for different
 objectives there are lot of duplicate efforts. For an example add user
 operation is included in all three services. Sometimes when you switch
 among different services for same functionality for an example
 UserInformationRecoveryService → registerUser to SCIM add user operation or
 UserAdmin add user operation you may find different data formats and
 performance issues due to different implementations.


 What is new for C5 ?
 What we are proposing new is reuse standard SCIM APIs for all user
 management functionalities.  Since SCIM 2.0 provide more comprehensive user
 management functionalities we can build common layer to serve all user
 management use cases for different channels. Basically User Admin can
 manage other identity accounts via SCIM APIs without having separate
 implementation.

>>>
>> Handling users/groups is an important aspect of IS and we should expose
>> these capabilities as a product API too, when industry adopted standard
>> present we should not define our own APIs hence +1 to use SCIM.
>>
>>
>>>
 Further we can extend the usage of SCIM for identity management
 functionalities as well. For an example we can achieve self sign up by
 sending anonymous SCIM request to SCIM '/Me' endpoint.

>>>
>> +1 explore more on this, BTW this feature should be align with
>> self-signup feature of user-portal, I mean this should support same lev

Re: [Architecture] [IS 6.0.0] Email Management Component Implementation

[Kasun Bandara]

Hi all,

When we were implementing the email management support for IS 5.3.0 the
idea was to use and integrate the generic WSO2 CEP Output Adaptor
module  (Including Email, SMS etc.) for email sending functionality, so we
can use this feature among other WSO2 products as well. AFAIK this has
already shipped with IS 5.3.0.

Thanks,
Kasun.


[1] http://mail.wso2.org/mailarchive/architecture/2015-April/019965.html

Kasun Gayan Bandara
PhD Research Student
Machine Learning Group

Faculty of Information Technology, Clayton
Monash University
25 Exhibition Walk, Clayton Campus
Wellington Road
Clayton VIC 3800
Australia.

E: herath.band...@monash.edu
M (+61) 43 491 6476





On Mon, Jan 23, 2017 at 5:58 PM, Dilan Udara Ariyaratne 
wrote:

> +1 to Sagara's point of view.
>
> It would be ideal if we can have one generic feature across the platform
> in sending rich-human-undersdanble messages such as E-mails and SMSs,
> so that it would cater any product having associated requirements at a
> higher level.
>
> @Lahiru, AFAIR, most recent EMM 2.2.0 and upcoming IoT releases have an
> in-built email sending feature at the product level itself to support
> associated requirements with device management.
> The decision to write an inbuilt email-sending feature with template
> support (using Velocity template engine) was made because of the fact that
> we never had one generic feature across the platform to achieve the same.
>
> Hope we can avoid any such duplication of the same capability across
> multiple products, once this feature is done.
>
> Thanks,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. 
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Mon, Jan 23, 2017 at 8:57 AM, Sagara Gunathunga 
> wrote:
>
>>
>> Sending E-mails is a very generic feature thus we have to make sure
>> whatever we do here can be reuse within the platform not just within IS.
>> Shall we arrange a discussion with Azeez, Suho and API-M folks before we
>> continue to discuss E-Mail specific Implementation details ?
>>
>> Also E-Mail is just one way of notification, we need some sort of a
>> generic framework/abstraction to send any type of  notification such as
>> SMS. Once we have such design we can implantation E-Mail support as one
>> notification type. I guess we can reuse most of the code/design from C4
>> based CEP module.
>>
>> Thanks !
>>
>> On Mon, Jan 23, 2017 at 8:29 AM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Isura,
>>>
>>> On Mon, Jan 23, 2017 at 8:21 AM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Danushka/Kasun,



 On Mon, Jan 23, 2017 at 7:00 AM, Kasun Bandara 
 wrote:

> Hi Lahiru,
>
> Is there any specific reason to populate the email configurations
> under 'config' directory ? . IMO these email template configurations must
> reside under 'Identity' directory structure.
>

 Email templates are not identity specific data. IMO email
 configurations should be in the conf directory, but not in Identity
 directory.

>>>
>>> Why we have email templates under identity directory in 5.3.0 is because
>>> we made a decision to contain all identity server features under one root
>>> directory, hence /identity. Not based on whether they are really a identity
>>> related feature or not. Same applies to event-mgt.properties file.
>>> Otherwise there can be naming conflicts coming from other repos. I also
>>> think all identity server features must go under one directory.
>>>
>>> Regards,
>>> Johann.
>>>
>>>
 Thanks
 Isura.

>
> Thanks,
> Kasun.
>
> Kasun Gayan Bandara
> PhD Research Student
> Machine Learning Group
>
> Faculty of Information Technology, Clayton
> Monash University
> 25 Exhibition Walk, Clayton Campus
> Wellington Road
> Clayton VIC 3800
> Australia.
>
> E: herath.band...@monash.edu
> M (+61) 43 491 6476
>
> 
>
>
>
> On Sun, Jan 22, 2017 at 10:10 PM, Lahiru Manohara 
> wrote:
>
>> Hi,
>>
>> We are implementing email management component for IS 6.0.0. The
>> following properties will be included in the email template.
>>
>> configuration:
>>  -
>>   subject:
>>   body:
>>   footer:
>>   type:
>>   display:
>>   locale:
>>   emailContentType:
>>
>> The following directory structure will be used to keep the template
>> based on the locale.
>>
>> config/
>> └── email/
>> ├── en_US
>> │└── email-admin-config.yaml
>> └── en_GB
>> └── email-admin-config.yaml
>>
>> Appreciate your suggestions on above design.
>>
>> Best Regards,
>> --
>> *Lahiru Manohara*
>> *Software Engineer*
>> Mobile: +94716561576
>> WSO2 Inc. | http://wso2.com
>> lean.e