Re: [Architecture] [Iam-dev] [Dev] [VOTE] Release WSO2 Identity Server 5.10.0 RC2

[Isura Karunaratne]

Hi All,

Tested the following flows and no blocking issues found.

   - Account Locking
   - Self user registration.
   - Password Policy

[+] Stable - go ahead and release.

Cheers,
Isura.

On Wed, Mar 11, 2020 at 12:07 PM Maduranga Siriwardena 
wrote:

> Hi All,
>
> Tested following authentication flows.
>
>- Federated authentication with OIDC
>- Inbound authentication with OIDC
>- Passwordless authentication with FIDO 2 using the Macbook
>fingerprint sensor
>
> No Blockers found.
> [+] Stable - go ahead and release.
>
> Regards,
> Maduranga.
>
> On Wed, Mar 11, 2020 at 11:41 AM Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi All,
>>
>> Tested following flows in UMA 2.0
>>
>>  1. Registration Endpoint
>>  2. Permission Endpoint
>>  3. Introspection Endpoint
>>  4. Obtaining an RPT using UMA Grant Type
>>  5. Obtaining an access token using Password Grant Type
>>
>> No Blockers found.
>>
>> [+] Stable - go ahead and release.
>>
>> Thanks,
>> Hasanthi
>>
>>
>> On Sun, Mar 8, 2020 at 11:26 PM Janak Amarasena  wrote:
>>
>>> Hi all,
>>>
>>> We are pleased to announce the second release candidate of WSO2 Identity
>>> Server 5.10.0.
>>>
>>>
>>> *New Features:*
>>>
>>>1. Passwordless authentication support
>>>2. An improved User Portal
>>>3. New RESTful APIs for user self-services and server management
>>>4. Scope based authorization for internal REST APIs
>>>5. Unique User ID support
>>>6. Tenant wise email-sender configuration
>>>
>>>
>>>
>>> *Fixes:*
>>> This release includes the following issue fixes and improvements:
>>>
>>>- 5.10.0-M1
>>>
>>>- 5.10.0-M2
>>>
>>>- 5.10.0-M3
>>>
>>>- 5.10.0-M4
>>>
>>>- 5.10.0-M5
>>>
>>>- 5.10.0-M6
>>>
>>>- 5.10.0-M7
>>>
>>>- 5.10.0-M8
>>>
>>>- 5.10.0-M9
>>>
>>>- 5.10.0-Alpha
>>>
>>>- 5.10.0-Alpha2
>>>
>>>- 5.10.0-Alpha3
>>>
>>>- 5.10.0-Beta
>>>
>>>- 5.10.0-Beta2
>>>
>>>- 5.10.0-Beta3
>>>
>>>- 5.10.0-GA
>>>
>>>
>>>
>>> *Source and Distribution*
>>> The source and distribution
>>> 
>>>  are
>>> available at https://github.com/wso2/product-is/releases/tag/v5.10.0-rc2
>>>
>>>
>>> Please download the product, test it, and vote using the following
>>> convention.
>>> [+] Stable - go ahead and release
>>> [-] Broken - do not release (explain why)
>>>
>>>
>>> Thank you,
>>> WSO2 Identity and Access Management Team
>>>
>>> --
>>> *Janak Amarasena* | Senior Software Engineer | WSO2 Inc.
>>> (m) +9464144 | (w) +94112145345 | (e) ja...@wso2.com
>>>
>>>
>>> 
>>> ___
>>> Iam-dev mailing list
>>> iam-...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>>>
>>
>>
>> --
>>
>> Hasanthi Dissanayake | Associate Technical Lead | WSO2 Inc.
>> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com  | Blog:
>> https://medium.com/@hasanthipurnimadissanayake
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> *Maduranga Siriwardena* | Technical Lead | WSO2 Inc.
> (m) +94718990591 | madura...@wso2.com
>
> 
> ___
> Iam-dev mailing list
> iam-...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>


-- 

*Isura Dilhara Karunaratne*
Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : https://medium.com/@isurakarunaratne
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] IAM Controller(IAM-CTL)- Command Line Extension for WSO2 Identity Server

[Isura Karunaratne]

Hi Godwin,

On Tue, Jan 21, 2020 at 5:14 PM Godwin Shrimal  wrote:

> Hi Piyumi,
>
> Interesting to see this and please share the low level design details when
> those are ready. I hope we can(will) implement other areas such as user
> store, identity provider etc with this CLI and please keep the design/user
> experience flexible to those without stick only into service providers.
>

Yes. This is the start point and the idea is to enhance this tool CLI
support other areas you mentioned as well.

Cheers,
Isura.

>
> Thanks
> Godwin
>
> On Mon, Jan 20, 2020 at 9:26 AM Piyumi Madhubhashini 
> wrote:
>
>> Hi all,
>>
>> We have started to implement the command line extension for Identity
>> server called IAM controller(IAM-CTL). This will enhance the developer’s
>> experiences of IAM artifact which is a service provider. It will help to
>> create service providers and view the list of  service providers easily
>> through the terminal. Initially, this command line extension will support
>> creating basic and oauth applications only.
>>
>> The command line extension will be implemented using Go language, cobra
>> and survey packages. The main reason to select the Go language is Go’s
>> program compiled as a static executable binary file. So it can be run
>> directly and there is no need to install external dependencies. Hence it is
>> unnecessary to worry about the various packages and library dependencies
>> required by the command line extension. So this makes deployment very
>> convenient.
>>
>> The command line extension will use Application Management REST API as
>> the endpoint of Identity Server. To authenticate, password grant type with
>> the Application Management REST API will be used.
>>
>> Here I have attached the high-level architecture as well.
>>
>>
>> Thanks and regards,
>>
>> --
>> *Piyumi Madhubhashini *| Intern- Engineering team | WSO2
>>
>> (m) +94778345567 | (e)  piyu...@wso2.com
>>
>> [image: http://wso2.com/signature] 
>>
>
>
> --
> Godwin Amila Shrimal | Technical Lead | WSO2 Inc.
> (m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) god...@wso2.com
> 
>


-- 

*Isura Dilhara Karunaratne*
Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : https://medium.com/@isurakarunaratne
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Supporting email verification when user’s email address is updated

[Isura Karunaratne]

Hi Dewni,


On Tue, Dec 10, 2019 at 5:50 PM Dewni Weeraman  wrote:

> Hi all,
>
> Currently, WSO2 Identity Server only supports email account verification
> during the self-registration and user onboarding process. There is no
> feature to trigger the email verification via email notification in a
> scenario where the user’s email address is updated.
>
It would be better if we can generalize the same feature to the other
claims as well.  For example, support email verification for first name,
last name updates.

Cheers,
Isura.

>
>
To address this limitation, we will be modifying
> the UserEmailVerificationHandler [1] to trigger the email account
> verification process when "emailaddress" claim has been updated. In order
> to achieve this, the events PRE_SET_USER_CLAIM and POST_SET_USER_CLAIM will
> be subscribed with the UserEmailVerificationHandler. To persist the changed
> email address till account verification happens we wish to introduce a new
> claim called "verificationPendingEmail". Upon email account verification,
> the new email address will be persisted against the "emailaddress" claim.
>
> In a scenario where the user updates the profile with the same email
> address which has already been verified, we have made the decision not to
> trigger an email verification.
>
> Please find attached the draft user stories and solution implementation
> documentation.
>
> [1]
> https://github.com/wso2-extensions/identity-governance/blob/master/components/org.wso2.carbon.identity.recovery/src/main/java/org/wso2/carbon/identity/recovery/handler/UserEmailVerificationHandler.java
>
>
> Kind regards,
> Dewni Weeraman
>
> --
> Dewni Weeraman | Software Engineer | WSO2 Inc.
> (m) +94 077 2979049 | (e) de...@wso2.com 
>
> 
>
>
>

-- 

*Isura Dilhara Karunaratne*
Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : https://medium.com/@isurakarunaratne
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] WSO2 Identity Server REST API Error Response Standardization

[Isura Karunaratne]

Hi Sominda,

I think it is better to start all the client errors with 400 (Ex USR-400xx)
and server errors with 500 (Ex USR-500xx). In this way, we can get some
understanding of the error by looking at the error code.

Cheers,
Isura.

On Thu, Aug 29, 2019 at 2:44 PM Sominda Gamage  wrote:

> Hi all,
>
> Currently, the REST APIs of Identity Server have different error codes
> such as (20018, 20048, etc.). The error codes in this format have less
> information regarding the cause or where it has occurred.
>
> Therefore, we would like to maintain the error codes which are used in our
> REST APIs in one commonplace. Currently, we are standardizing error codes
> along with their details and this is still a work in progress.
>
> According to this effort, sample error code will look like “
> -
>
> Eg: CQM-10005
>
> The Prefix (first part) indicates the component. In this case, CQM
> indicates Challenge Questions Management.
> The error-identifier-number (the second part of the error code) reflects
> the numerical identifier for the error.
>
> For the rest APIs, we have defined 2 types of codes for both user and
> server APIs.
>
>-
>
>Success codes: For successful operations
>-
>
>Error codes: For error scenarios
>-
>
>   Client Errors
>   -
>
>   Server Errors
>
>
>
> *Success Codes*
>
> Despite the API type, all the success codes will start from 02000 onwards.
> To maintain consistency, a zero will be added at the beginning.
>
> Eg: USR-02001
>
> The above Success Code indicates a successful User Self Registration.
>
>
> *Error Codes*
>
> With the introduction of API error standards, we wish to standardize the
> error response from an API. Therefore, a sample API error response will be
> as follows.
>
> {
>
> “code” : “some_error_code”,
>
> “Message” : “some_error_message”,
>
> “Description” : “some_error_description”,
>
> “traceID” : “correlation_id”
>
> }
>
> A correlationId has been introduced to log the error and send with the
> response
>
>
> *User API errors*
>
> User APIs has two types of errors.
>
>1.
>
>Client errors
>2.
>
>Server errors
>
> *Client Errors in user APIs*
>
> For client errors in user APIs, we have allocated the range starting from
> 100.
>
> Eg: USR-100xx
>
> *Server Errors in user APIs*
>
> For server errors in user APIs, we have allocated the range starting from
> 100.
>
> Eg: USR-150xx
>
>
> *Server API Errors*
>
> Server APIs has two types of errors.
>
>1.
>
>Client errors
>2.
>
>Server errors
>
> *Client errors in server APIs*
>
> For client errors in server APIs, we have allocated the range starting
> from 500.
>
> Eg: USR-500xx
>
> *Server Errors in server APIs*
>
> For server errors in server APIs, we have allocated the range starting
> from 550.
>
> Eg: USR-550xx
>
>
> This will be the new standardization for Rest API Success and Error
> responses.
>
>
> Thanks & Regards,
>
> Sominda.
>
> --
> *Sominda Gamage* | Software Engineer| WSO2 Inc. 
> (M)+94 719873902 | (E) somi...@wso2.com
> 
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 

*Isura Dilhara Karunaratne*
Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : https://medium.com/@isurakarunaratne
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM][IS 5.10.0] REST APIs For Federated Associations Of The User

[Isura Karunaratne]

Hi Tharindu,

On Tue, Oct 29, 2019 at 2:43 PM Tharindu Bandara  wrote:

> Hi, Darshana/All,
>
> If we are doing any backend changes for this API, I suggest to do those in
>> identity-user-account-association[1], not in UserProfileAdmin.
>
>
> +1. I have initially planned to re-use UserProfileAdmin as it seemed to
> serve all the requirements thus we would not do the backend changes. But
> alongside with the concern raised by @Farasath Ahamed  in
> [2], I will move the backend implementation to the
> identity-user-account-association[1] as this would be a much cleaner
> approach.
>
> To give an update on the progress,
>
> I have added two more APIs to create federated associations.
>
>- [POST] : /me/federated-associations
>   - Associate a federated user to the authenticated user.
>
> I think this API is not required. If this is supported, anyone can
associate federated accounts without authentication. That can cause a
security issue.

Cheers,
Isura.

>
>- [POST] : /{user-id}/federated-associations
>   - Associate Federated users
>
> Please find the swagger definition[3] of the improved API which will be
> updated along the way.
>
> [1] https://github.com/wso2-extensions/identity-user-account-association
> [2]
> https://github.com/wso2/carbon-identity-framework/pull/2499#discussion_r339903378
> [3] https://app.swaggerhub.com/apis/WSO8/association/v1
>
> Regards,
> Tharindu.
>
> On Tue, Oct 29, 2019 at 11:52 AM Darshana Gunawardana 
> wrote:
>
>> If we are doing any backend changes for this API, I suggest to do those
>> in identity-user-account-association[1], not in UserProfileAdmin.
>>
>> [1] https://github.com/wso2-extensions/identity-user-account-association
>>
>> Thanks,
>>
>> On Tue, Oct 29, 2019 at 11:41 AM Tharindu Bandara 
>> wrote:
>>
>>> Hi all,
>>>
>>> WSO2 Identity Server has REST APIs for user account associations[1]. As
>>> of now these APIs provide the capability to work with local user account
>>> associations and do not support federated user account associations.
>>>
>>> I have been working on this to support federated user account
>>> associations with the User Account Associations API[1]. As planned, the
>>> following APIs will be added with this effort.
>>>
>>>- [GET] : /me/federated-associations
>>>   - Retrieve the federated associations of the authenticated user.
>>>- [GET] : /{user-id}/federated-associations
>>>   - Get user's federated associations
>>>   - [DELETE] : /me/federated-associations
>>>   - Delete all my federated user associations
>>>   - [DELETE] : /{user-id}/federated-associations
>>>- Delete user's all user federated associations
>>>
>>> I am also evaluating the possibility of adding an API to create
>>> federated associations. I will update this thread with the progress.
>>>
>>> The internal implementation for the above APIs will use the
>>> UserProfileAdmin[2] underneath(The UserProfileAdmin[2] is used by the
>>> UserProfileMgtService) through the OSGi framework. In the early
>>> discussions, we have tested registering the UserProfileAdmin[2] directly as
>>> an OSGi service, but we will discuss it further to find the optimum
>>> approach.
>>>
>>> Please provide your valuable feedback on this.
>>>
>>> [1] https://is.docs.wso2.com/en/next/develop/association-rest-api/#/
>>> [2]
>>> https://github.com/wso2/carbon-identity-framework/blob/master/components/user-mgt/org.wso2.carbon.identity.user.profile/src/main/java/org/wso2/carbon/identity/user/profile/mgt/UserProfileAdmin.java
>>>
>>> Regards,
>>> --
>>> *Tharindu Bandara*
>>> Senior Software Engineer | WSO2
>>>
>>> Email : tharin...@wso2.com
>>> Mobile : +94 714221776
>>> web : http://wso2.com
>>> 
>>>
>>> https://wso2.com/signature
>>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859*Lean . Enterprise . Middleware
>>
>
>
> --
> *Tharindu Bandara*
> Senior Software Engineer | WSO2
>
> Email : tharin...@wso2.com
> Mobile : +94 714221776
> web : http://wso2.com
> 
>
> https://wso2.com/signature
>


-- 

*Isura Dilhara Karunaratne*
Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : https://medium.com/@isurakarunaratne
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Discussion point on Federated Account Linking

[Isura Karunaratne]

Hi Johann,

On Mon, Jun 10, 2019 at 12:08 PM Johann Nallathamby  wrote:

> *Meeting Notes - 30/5/2019*
>
> During the meeting for [1], we also identified some federated account
> linking improvements that are currently not supported in WSO2 IS.
>
> A single physical user may have a set of linked local accounts in WSO2
> Identity Server. The same physical user may have one or more federated
> identities also.
>
> *Problems*
>
> 1. How to reliably link all the federated identities to the set of linked
> local accounts?
>
> 2. How do we allow users to login with any one of the federated accounts
> and get mapped to the primary local account or one of the other local
> accounts based on either configuration or user input and login to service
> provider?
>
> 3. Cannot link multiple federated accounts in the same IdP to a single
> local account. This could be a valid requirement.
>
> *Solutions*
>
> 1. How to reliably link all the federated identities to the set of linked
> local accounts?
>
> We do have just-in-time provisioning and linking in the same request.
> However, we don't have just-in-time linking to an existing user account.
> The reason being that we don't have just-in-time verification of ownership
> of the link identifier. For example, if the linking is done based on email
> address on both sides, the email address coming from the IdP must be
> verified. If we can't be sure if its verified, then it can result in an
> account takeover. Therefore we haven't allowed this capability
> out-of-the-box.
>
> However, in a particular deployment if we can make sure that the ownership
> of the link identifier is independently verified on both sides, then we can
> implement an extension and do the federated account linking.
>
> In order to implement the just-in-time link identifier verification, we
> can extend the federated account linking handler, find if a user exists
> with the link identifier, and set the "http://wso2.org/claims/verifyEmail;
> claim of that user to 'true'. This will initiate the email address
> verification flow for that particular user and send out a verification
> email to the user's given email address. Once the user logs into his email
> account and confirms the account, user will be directed to IS's portal, and
> a web service will be invoked to link the identified user to the federated
> account used to login.
>
We can set http://wso2.org/claims/verifyEmai
 claim when we provision users to the
Identity Server. There can be a situation where the user is already
existing. In that case, we don't need to provision user again, but we
should send an email to confirm the identifier and link the account.

Since the Email Verification feature is currently supported only for the
user onboarding, we have to improve the feature for supporting existing
users as well.

>
> In this flow we may have to track the federated account identifier
> throughout the flow. This can be passed as a property to the notification
> handler and added as a URL parameter in the email confirmation link.
>
> Another problem which was discussed is that we can't directly link a
> federated account to multiple local accounts. Alternatively we can link the
> federated account to a single primary local account and link all the other
> local accounts to the primary account via local account linking.
>
> 2. How do we allow users to login with any one of the federated accounts
> and get mapped to the primary local account or one of the other local
> accounts based on either configuration or user input and login to service
> provider?
>
> Linking federated account identifier to the primary local account and
> logging in, is support today. What is not supported is allowing to pick a
> linked local account to the primary local account based on configuration or
> user input for a particular service provider. This can be implemented using
> a PostAuthenticationHandler.
>

I think this is required when there are multiple linked local accounts for
the federated account identifier. What is the expectation of selecting a
linked local account while logging in? Is that to send the claims of the
selected local accounts to the Application side?

Cheers,
Isura.

>
> [1] "[IAM] What is our Strategy on Local Account Linking?" in
> architecture@wso2.org
>
> Thanks & Regards,
> Johann.
>
> --
> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
> WSO2 Inc.
> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
> [image: Signature.jpg]
>


-- 

*Isura Dilhara Karunaratne*
Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : https://medium.com/@isurakarunaratne
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev][IAM] Moving File Based Artifacts to Artifact Store

[Isura Karunaratne]

On Wed, Jun 5, 2019 at 9:34 AM Ruwan Abeykoon  wrote:

> Hi All,
> The "User Store" configuration can be considered as a deployment artifact
> if we look at the following aspects.
>
> a) "Secondary User Stores" are added, removed and updated per tenant
> basis. (Same as SP, and IdP configs)
> b) "User Store", "IdP" and "SP", XACML policies, etc behaves as a
> collection of business rules, defining the authentication and authorization
> flows per the tenant.
> c) A change in a particular "User Store" usually affect the
> "Authentication" decisions done via SP config. Hence they have tight
> coupling.
> d) All "User Store", "SP", "IdP", etc, need to be taken as one unit, when
> we consider environment to environment promotion of these configs.
> (Dev->QA->staging->Prod)
>
> Hence IMHO, treating "User Store" as the file-based artifact was a right
> decision, when our products have been designed for deployment on bear-metal
> or VM. However moving forward to container, and cloud nativeness, posses
> the challenge on sharing these artifacts.
>
> Also, considering the CI/CD pipelines, the governance aspect of changing
> the configurations, etc, these type of configs need to be considered as
> artifacts. We might need to version control these artifacts in future and
> may need to push and pull them from VCS systems.
>
> What we need to do is to have a delegation pattern implemented for all
> current file based (and registry based artifacts), where we can switch the
> repository from file based one to different system. DB based repository
> would be the first such(simple) implementation. We may need to implement
> Git based repository when we properly support cloud use cases for example.
> We can abstract the storage system, and retain all the parsing and
> generation logic unchanged for artifacts. it would be a minimal change and
> most versatile way to extend IMO.
>
> We would need to implement property or "environment variable" binding
> logic, to get proper support for environment to environment promotion of
> artifacts. yet, it can be done with a separate effort than this IMO.
>
> Hence +1 to treat
>
>- Persist data as a blob (marshalled to text form)
>- In a separate table structure.
>
> Cheers,
> Ruwan A
>
>
> On Tue, Jun 4, 2019 at 3:50 PM Johann Nallathamby  wrote:
>
>> +1 to get rid of the artifacts for user stores. I think this was a wrong
>> decision we made early on.
>>
>> On Tue, Jun 4, 2019 at 1:19 PM Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> *Problem *
>>> Currently, some artifacts like userstores , tenants' data, etc are
>>> stored in the file system (not in the database). So when using a clustered
>>> setup those artifacts should be shared among all the nodes by using one of
>>> the following file sharing mechanisms.
>>>
>>>- Dep Sync
>>>- rSync
>>>- Shared File System
>>>
>>>
>>> *Solution *
>>> In order to avoid a shared file system and to reduce the deployment and
>>> maintenance overhead, those artifacts ca be persisted in the database
>>> itself.
>>>
>>> *Approach*
>>> After discussing with @Ruwan Abeykoon   and @Isura
>>> Karunaratne  we have two options to persist above
>>> discussed artifact details.
>>>
>>>- In the configuration store which is already implemented as
>>>discussed in [1][2].
>>>- In a separate table structure.
>>>
>>> If we are to go with option 01, then we need to consider the artifacts
>>> as configurations and persist in the existing schema.
>>>
>> The advantage of using this is we can re-use the existing implementation
>>> including the database schema and existing rest APIs and functionalities
>>> (pagination, searching, etc) .
>>>
>>
>>
>
Hi all,


> The drawback is the conceptual difference between an artifact and
>>> configuration.
>>>
>>
>> I think this is not a problem. In fact I believe we made a wrong decision
>> of considering user stores as artifacts. I can't remember exactly as to why
>> we decided like that. User stores are not development artifacts; they are
>> one time configurations. They don't have metadata, versioning, lifecycles
>> or any other properties associated with other artifacts in WSO2.
>>
>>
>>> Further if we are to use the configuration store there is no way to
&g

Re: [Architecture] [Dev] [VOTE] Release WSO2 Identity Server 5.8.0 RC3

[Isura Karunaratne]

Hi all,

Tested following features and no issues found.

   - Self User Registration
   - Password Policy
   - Password History
   - Password Recovery
   - Account Locking

[+] Stable - go ahead and release.

Cheers,
Isura.

On Wed, May 22, 2019 at 8:07 PM Farasath Ahamed  wrote:

> Hi All,
>
> Test the below scenarios in IS 5.8.0 RC3 pack.
>
>- Token revocation with authorization code reuse
>- OIDC UserInfo with token sent in the request body and as bearer
>header
>- OAuth Application Owner update
>- Verified no username enumeration attacks possible during password
>recovery flows.
>
>
> [+] Stable - go ahead and release.
>
>
> Regards,
> Farasath
>
> On Wed, May 22, 2019 at 5:41 PM Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi All,
>>
>> I have tested following features.
>>
>>1. OIDC backchannel logout
>>2. SAML front channel logout.
>>
>> No blocking issues found.
>>
>> [+] Stable - go ahead and release.
>>
>> Thanks,
>> Hasanthi
>>
>>
>>
>> On Wed, May 22, 2019 at 8:03 AM Isuranga Perera 
>> wrote:
>>
>>> All:
>>> I have tested Federated Authentication
>>> [+] Stable - go ahead and release.
>>>
>>> Best Regards
>>> Isuranga Perera
>>>
>>> On Sun, May 19, 2019 at 7:30 PM Shanika Wickramasinghe <
>>> shani...@wso2.com> wrote:
>>>
 Hi All,

 I have tested the SAML SSO with POST binding and Redirect binding flows
 and no issues found.

 +1 Go Ahead and Release


 Thanks,

 Shanika

 On Thu, May 16, 2019 at 12:33 PM Hasanthi Purnima Dissanayake <
 hasan...@wso2.com> wrote:

> Hi All,
>
> The reason of breaking the RC2 vote is because it is reported an
> unused commented configuration description in carbon.xml [1]. From RC3
> release that commented line in the configuration file is removed and no
> other code level changes done.
>
> Further in the Analytics-IS pack, the versions are updated according
> to the latest released SP pack versions [2].
>
> [1] [Dev][VOTE] Release WSO2 Identity Server 5.8.0 RC2
> [2] [VOTE] Release of WSO2 Stream Processor 4.4.0 RC6
>
> Thanks,
> Hasanthi
>
> On Thu, May 16, 2019 at 12:30 PM Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi all,
>>
>> We are pleased to announce the third release candidate of WSO2
>> Identity Server 5.8.0.
>>
>> This release fixes the following issues,
>>
>>- 5.8.0-RC3 fixes
>>
>>- 5.8.0-RC2 fixes
>>
>>- 5.8.0-RC1 fixes
>>
>>- 5.8.0-Beta5 fixes
>>
>>- 5.8.0-Beta4 fixes
>>
>>- 5.8.0-Beta3 fixes
>>
>>- 5.8.0-Beta fixes
>>
>>- 5.8.0-Alpha5 fixes
>>
>>- 5.8.0-Alpha4 fixes
>>
>>- 5.8.0-Alpha3 fixes
>>
>>- 5.8.0-Alpha2 fixes
>>
>>- 5.8.0-Alpha fixes
>>
>>- 5.8.0-M26 fixes
>>
>>- 5.8.0-M25 fixes
>>
>>- 5.8.0-M24 fixes
>>
>>- 5.8.0-M6 fixes
>>
>>- 5.8.0-M5 fixes
>>
>>- 5.8.0-M4 fixes
>>
>>- 5.8.0-M3 fixes
>>
>>- 5.8.0-M2 fixes
>>
>>- 5.8.0-M1 fixes
>>
>>
>>
>> Source and distribution
>>
>> Runtime - https://github.com/wso2/product-is/releases/tag/v
>> 
>> 5.8.0-rc3
>> 
>> Analytics -
>> https://github.com/wso2/analytics-is/releases/tag/v5.8.0-rc3
>> 

Re: [Architecture] Cloud Tenant deletion caching issue

[Isura Karunaratne]

Hi Pushpalanka,

We fixed this by using caches for tenantIdDomainMap and tenantDomainIdMap.
Once an item is removed from a node, other nodes' same cache will be
invalidated using local cache invalidations cluster messages.

Cheers,
Isura.

On Thu, Feb 21, 2019 at 7:41 PM Pushpalanka Jayawardhana 
wrote:

> Hi All,
>
> On Wed, 10 Sep 2014 at 21:13, Godwin Amila Shrimal 
> wrote:
>
>> Hi,
>>
>> As per the discussion had with Azeez offline please see below the
>> solution agreed.
>>
>> 1. Add a new overload method to *TenantManager *as *void
>> deleteTenant(int tenantId, boolean removeFromPersistentStorage) throws
>> UserStoreException;*
>>
>> 2. Implement this method in *JDBCTenantManager *class which use to
>> delete only the map entry and execute in each worker nodes by calling
>> from Cluster message.
>>
>> 3. Modify existing deleteTenant(int tenantId) to delete the persistent
>>  storage which is calling in management node.
>>
>> Please see below modified code snippet in *JDBCTenantManager*
>>
>>
>>  @Override
>> public void deleteTenant(int tenantId) throws UserStoreException {
>> try {
>> deleteTenant(tenantId, true);
>> } catch (org.wso2.carbon.user.api.UserStoreException e) {
>> throw new UserStoreException(e);
>> }
>> }
>>
>> @Override
>> public void deleteTenant(int tenantId, boolean
>> removeFromPersistentStorage)
>> throws org.wso2.carbon.user.api.UserStoreException {
>> // Remove tenant information from the cache.
>> String tenantDomain = (String) tenantIdDomainMap.remove(tenantId);
>> tenantDomainIdMap.remove(tenantDomain);
>>
>> tenantCacheManager.clearCacheEntry(new TenantIdKey(tenantId));
>>
>> if (removeFromPersistentStorage) {
>> Connection dbConnection = null;
>> PreparedStatement prepStmt = null;
>> try {
>> dbConnection = getDBConnection();
>> String sqlStmt = TenantConstants.DELETE_TENANT_SQL;
>> prepStmt = dbConnection.prepareStatement(sqlStmt);
>> prepStmt.setInt(1, tenantId);
>>
>> prepStmt.executeUpdate();
>> dbConnection.commit();
>> } catch (SQLException e) {
>> DatabaseUtil.rollBack(dbConnection);
>> String msg = "Error in deleting the tenant with " +
>> "tenant id: "
>> + tenantId + ".";
>> log.error(msg, e);
>> throw new UserStoreException(msg, e);
>> } finally {
>> DatabaseUtil.closeAllConnections(dbConnection,prepStmt);
>> }
>> }
>> }
>>
>> Did we follow this approach and fix this?
> Appreciate some details on how this issue was overcome.
>
> Thanks,
> Pushpalanka
>
>>
>>
>> Thanks
>> Godwin
>>
>>
>>
>>
>> On Tue, Sep 9, 2014 at 6:04 PM, Godwin Amila Shrimal 
>> wrote:
>>
>>> Yes, there are two maps as *tenantDomainIdMap* and *tenantIdDomainMap*.
>>> we'll address both.
>>>
>>>
>>>
>>> On Tue, Sep 9, 2014 at 5:23 PM, Amila Maha Arachchi 
>>> wrote:
>>>
 +1

 I remember there were two maps or a bidi-map. i.e. It was tracking both
 tenant ID and tenant domain. Make sure both issues are addressed (if my
 concern is valid).

 On Tue, Sep 9, 2014 at 3:37 AM, Godwin Amila Shrimal 
 wrote:

> Hi.
>
> We had a discussion about cleaning cache data (delete map entry in
> *JDBCTenantManger*), As per the discussion, we have to use cluster
> message to notify all the nodes in the clustered environment to
> delete the map entry.  Then we have to give a public method in
> *JDBCTenantManger* to delete the entry which is accessible from the
> *execute* method of the cluster message.
>
> listed below the summary of the implementation.
>
> 1. Create a new public method in *JDBCTenantManger *to delete the map
> entry.
> 2. Create a new class which extends ClusteringMessage and implements
> Serializable.
> 3. Implement the *execute* method on above class to perform the
> delete map entry method inside the *JDBCTenantManger.*
> 4. When execute the deleteTenant method in *TenantMgtAdminService, *create
> a object from new Cluster Message class created in #2 and set the tenantId
> as a property and send to all nodes in the cluster.
> 5. Nodes will receive the above message, deserialize it and perform
> the execute method of the cluster message, which will delete the map entry
> in each nodes.
>
>
> Please give a feedback on this.
>
>
> Thanks
> Godwin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Sep 8, 2014 at 10:07 AM, Godwin Amila Shrimal  > wrote:
>
>> Hi All,
>>
>> Thanks for the valuable responses, As I understood we have to use cluster
>> messages(Which I 

Re: [Architecture] [IS] JDBC based Configuration Store for WSO2 IS

[Isura Karunaratne]

Hi Chamila,

On Tue, Dec 4, 2018 at 10:38 AM Chamila De Alwis  wrote:

> Hi Tharindu, IS team,
>
> A quick clarification. Is this related to storing product configuration in
> a DBMS or are these only the configurations created at runtime? If it is
> the former, is this going to (gradually?) replace the XML config files?
>
> This is not a replacement for xml config files. Main objective is to store
tenant wise configurations at runtime.

Cheers,
Isura.

>
> *Chamila de Alwis* | Associate Technical Lead | WSO2 Inc.
> (m) +94 77 220 7163 | (e) chami...@wso2.com
> [image: Get Integration Agile] 
>
>
>
> On Wed, Oct 17, 2018 at 12:11 PM Tharindu Bandara 
> wrote:
>
>> Hi Farasath,
>>
>> The current plan is to manage email configurations per tenant.
>>
>> In the future, we can move similar tenant wise configurations to here. A
>> few examples would be email templates, challenge questions, issuer details.
>>
>> Thanks,
>> Tharindu.
>>
>> On Wed, Oct 17, 2018 at 11:53 AM Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Wed, Oct 17, 2018 at 10:36 AM Tharindu Bandara 
>>> wrote:
>>>
 Hi all,

 I have been working on the $subject as WSO2 IS need a common place to
 store configurations.

>>>
>>> Can you give some examples for the types of configurations we plan to
>>> manage with this endpoint?
>>>
>>>

 Above diagramme is a high-level, modularized view of $subject approach.

 I am working on the Configuration Management Endpoint. Below include
 the REST API for this.

 Name : WSO2 Identity Server Configuration Management Rest API

 Base URL : {tenant-domain}/api/identity/config-mgt/v1.0

 URL

 Method

 Body

 Description

 /configuration

 POST

 Tenant Configurations object

 Add configurations

 PUT

 Tenant Configurations object

 Add or Replace configurations

 PATCH

 Tenant Configurations object

 Update existing configurations

 GET

 -

 Retrieve configurations

 DELETE

 -

 Revoke configurations

 /configuration/{key}

 POST

 Configuration object

 Add the configuration

 PUT

 Configuration object

 Add or Replace the configuration

 PATCH

 Configuration object

 Update existing configuration

 GET

 -

 Retrieve the configuration

 DELETE

 -

 Revoke the configuration

 A path parameter named ‘key’ is used to identify a configuration.

 Path Parameter

 Description

 {key}

 Key of the configuration

 Two types of data objects are used for above REST API calls.

 Data object

 Model

 Tenant Configurations object

 Configuration object


 Let’s have a look at an example POST request to add the “email
 configuration” using WSO2 Identity Server Configuration Management Rest 
 API.

 Method

 POST

 URL

 /api/identity/config-mgt/v1.0/configuration/email

 Body


 Please refer to the detailed REST API documentation for in-depth
 information[1]
 
 .

 Please note that naming in the API is not finalized yet.

 Your valuable comments and suggestions are highly appreciated.


 [1]
 https://app.swaggerhub.com/apis-docs/WSO8/wso-2_identity_server_configuration_management_rest_api/1.0.0
 

 Thanks,

 Tharindu.
 --
 *Tharindu Bandara*
 Software Engineer | WSO2

 Email : tharin...@wso2.com
 Mobile : +94 714221776
 web : http://wso2.com
 

 https://wso2.com/signature

>>>
>>>
>>> --
>>> Farasath Ahamed
>>> Senior Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>>
>>
>> --
>> *Tharindu Bandara*
>> Software Engineer | WSO2
>>
>> Email : tharin...@wso2.com
>> Mobile : +94 714221776
>> web : http://wso2.com
>> 
>>
>> https://wso2.com/signature
>>
>

-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org

Re: [Architecture] [IAM][JDBC based Configuration Store] Database Schema

[Isura Karunaratne]

Also, let's remove the unique index of CONFIG_ID in IDN_CONFIG_FILE table.
Then we can maintain multiple files for a given resource.

Cheers,
Isura.

On Tue, Dec 4, 2018 at 9:37 AM Tharindu Bandara  wrote:

> Hi Isura,
>
> We better to restrict this in API level since there is no need of having
>> config resources without config attributes or config file.
>
>
> +1. I will add this restriction in the API level.
>
> Thanks,
> Tharindu.
>
> On Tue, Dec 4, 2018 at 9:24 AM Isura Karunaratne  wrote:
>
>> Hi Tharindu,
>>
>> According to the database schema, we can add config resources without any
>> config attribute or config file. We better to restrict this in API level
>> since there is no need of having config resources without config attributes
>> or config file.
>>
>> Cheers,
>> Isura.
>>
>> On Mon, Dec 3, 2018 at 6:13 PM Tharindu Bandara 
>> wrote:
>>
>>> Hi all,
>>>
>>> Following is the diagramme for the $subject. Configuration store REST
>>> API for WSO2 IS[2] will be refactored to support this.
>>>
>>>
>>> Above diagramme is based on the following key points as discussed in the
>>> review meeting[1].
>>>
>>>
>>>-
>>>
>>>Resources will be grouped under its type. Ex: For resources grouped
>>>under the issuer, type would be the issuer.
>>>-
>>>
>>>A resource can either contain a file or not. Ex: Email template file
>>>for the email resource.
>>>-
>>>
>>>A resource can contain zero or more attributes. Ex: For an email
>>>resource, from and to values are attributes.
>>>-
>>>
>>>Attributes and the file will be kept in separate tables and boolean
>>>flags will be included in the resource table to indicate the existence of
>>>each category.
>>>
>>> [1] "Invitation: [IAM][Review]JDBC Based Configuration Store @ Mon Dec
>>> 3, 2018 1pm - 2pm (IST) (WSO2 Engineering Group)"
>>>
>>> [2] "[Architecture] [IS] JDBC based Configuration Store for WSO2 IS"
>>>
>>> Thanks,
>>>
>>> Tharindu.
>>> --
>>> *Tharindu Bandara*
>>> Software Engineer | WSO2
>>>
>>> Email : tharin...@wso2.com
>>> Mobile : +94 714221776
>>> web : http://wso2.com
>>> <https://www.google.com/url?q=http://wso2.com=D=151765338399=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg>
>>>
>>> https://wso2.com/signature
>>>
>>
>>
>> --
>>
>> *Isura Dilhara Karunaratne*
>> Associate Technical Lead | WSO2 <http://wso2.com/>
>> *lean.enterprise.middleware*
>> Email: is...@wso2.com
>> Mob : +94 772 254 810
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>>
>
> --
> *Tharindu Bandara*
> Software Engineer | WSO2
>
> Email : tharin...@wso2.com
> Mobile : +94 714221776
> web : http://wso2.com
> <https://www.google.com/url?q=http://wso2.com=D=151765338399=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg>
>
> https://wso2.com/signature
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2 <http://wso2.com/>
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM][JDBC based Configuration Store] Database Schema

[Isura Karunaratne]

Hi Tharindu,

According to the database schema, we can add config resources without any
config attribute or config file. We better to restrict this in API level
since there is no need of having config resources without config attributes
or config file.

Cheers,
Isura.

On Mon, Dec 3, 2018 at 6:13 PM Tharindu Bandara  wrote:

> Hi all,
>
> Following is the diagramme for the $subject. Configuration store REST API
> for WSO2 IS[2] will be refactored to support this.
>
>
> Above diagramme is based on the following key points as discussed in the
> review meeting[1].
>
>
>-
>
>Resources will be grouped under its type. Ex: For resources grouped
>under the issuer, type would be the issuer.
>-
>
>A resource can either contain a file or not. Ex: Email template file
>for the email resource.
>-
>
>A resource can contain zero or more attributes. Ex: For an email
>resource, from and to values are attributes.
>-
>
>Attributes and the file will be kept in separate tables and boolean
>flags will be included in the resource table to indicate the existence of
>each category.
>
> [1] "Invitation: [IAM][Review]JDBC Based Configuration Store @ Mon Dec 3,
> 2018 1pm - 2pm (IST) (WSO2 Engineering Group)"
>
> [2] "[Architecture] [IS] JDBC based Configuration Store for WSO2 IS"
>
> Thanks,
>
> Tharindu.
> --
> *Tharindu Bandara*
> Software Engineer | WSO2
>
> Email : tharin...@wso2.com
> Mobile : +94 714221776
> web : http://wso2.com
> 
>
> https://wso2.com/signature
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.8.0-M4 Released!

[Isura Karunaratne]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.8.0 M4!
Download

You can download WSO2 Identity Server 5.8.0 M4 from here

.

You can download WSO2 Identity Server Analytics 5.8.0 M4 from here

.
How to run

   1.

   Extract the downloaded zip file.
   2.

   Go to the bin directory in the extracted folder.
   3.

   Run the wso2server.sh file if you are on a Linux/Mac OS or run the
   wso2server.bat file if you are on a Windows OS.
   4.

   Optionally, if you need to start the OSGi console with the server, use
   the -DosgiConsole property when starting the server.

What's new in WSO2 Identity Server 5.8.0 M4

A list of all the new features and bug fixes shipped with this release can
be found here 

Known Issues

All the open issues pertaining to WSO2 Identity Server are reported at the
following location:

   -

   IS Runtime 
   -

   IS Analytics 

Contribute to WSO2 Identity ServerMailing Lists

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

   -

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

   Architecture List: architecture@wso2.org
   -

   User Forum: StackOverflow
   

Reporting Issues

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

For more information about WSO2 Identity Server, please see https://wso2
.com/identity-and-access-management or visit the WSO2 Oxygen Tank
 developer portal for additional resources.

~ The WSO2 Identity and Access Management Team ~



-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] JDBC based Configuration Store for WSO2 IS

[Isura Karunaratne]

Hi Tharindu,



On Wed, Oct 17, 2018 at 10:36 AM Tharindu Bandara 
wrote:

> Hi all,
>
> I have been working on the $subject as WSO2 IS need a common place to
> store configurations.
>
>
> Above diagramme is a high-level, modularized view of $subject approach.
>
> I am working on the Configuration Management Endpoint. Below include the
> REST API for this.
>
> Name : WSO2 Identity Server Configuration Management Rest API
>
> Base URL : {tenant-domain}/api/identity/config-mgt/v1.0
>
> URL
>
> Method
>
> Body
>
> Description
>
> /configuration
>
> POST
>
> Tenant Configurations object
>
> Add configurations
>
> PUT
>
> Tenant Configurations object
>
> Add or Replace configurations
>
> PATCH
>
> Tenant Configurations object
>
> Update existing configurations
>
> GET
>
> -
>
> Retrieve configurations
>
> DELETE
>
> -
>
> Revoke configurations
>
> /configuration/{key}
>
> POST
>
> Configuration object
>
> Add the configuration
>
> PUT
>
> Configuration object
>
> Add or Replace the configuration
>
> PATCH
>
> Configuration object
>
> Update existing configuration
>
> GET
>
> -
>
> Retrieve the configuration
>
> DELETE
>
> -
>
> Revoke the configuration
>
> A path parameter named ‘key’ is used to identify a configuration.
>

According to the swagger definition, the POST body of the adding a new
configuration is as follows. According to that, you need to use "name" as
the path paramter instead of "key".


{
  "configurations": [
{
  "name": "string",
  "attributes": [
{
  "key": "string",
  "value": "string"
}
  ]
}
  ]
}


Thanks
Isura.


>
> Path Parameter
>
> Description
>
> {key}
>
> Key of the configuration
>
> Two types of data objects are used for above REST API calls.
>
> Data object
>
> Model
>
> Tenant Configurations object
>
> Configuration object
>
>
> Let’s have a look at an example POST request to add the “email
> configuration” using WSO2 Identity Server Configuration Management Rest API.
>
> Method
>
> POST
>
> URL
>
> /api/identity/config-mgt/v1.0/configuration/email
>
> Body
>
>
> Please refer to the detailed REST API documentation for in-depth
> information[1]
> 
> .
>
> Please note that naming in the API is not finalized yet.
>
> Your valuable comments and suggestions are highly appreciated.
>
>
> [1]
> https://app.swaggerhub.com/apis-docs/WSO8/wso-2_identity_server_configuration_management_rest_api/1.0.0
> 
>
> Thanks,
>
> Tharindu.
> --
> *Tharindu Bandara*
> Software Engineer | WSO2
>
> Email : tharin...@wso2.com
> Mobile : +94 714221776
> web : http://wso2.com
> 
>
> https://wso2.com/signature
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Implementing SAML ECP profile for WSO2 IS

[Isura Karunaratne]

On Fri, Sep 28, 2018 at 11:32 AM Winma Heenatigala  wrote:

> Hi all,
>
> As I mentioned in my previous email, I completed my research on the ECP
> profile and started to implement it for WSO2 identity server.
>  For testing purposes I needed an ECP enabled Service Provider and a
> client. For that I used Shibboleth SP and a Simple Bash client[1] provided
> by Shibboleth.
>
> I created a new Servlet called SAMLECPProviderServlet  to capture the
> SOAP binded SAML authentication request sent by the Enhanced Client.The
> basic auth credentials (username and password) were sent by the client to
> the IDP in the http request authorization header. Using a request wrapper,
> basic auth credentials were set to the sectoken parameter, the saml request
> was extracted from the soap envelope and forwarded the new  request to the
> SAMLSSOProviderServlet. Then the request could process in the way that the
> Request Path Authenticator works. Inside the SAMLSSOServlet , for the
> requests from the ECP clients a separate response was created where the
> saml response was enclosed in a soap envelope.
>
> However, since the client is browserless there is an issue in providing
> user consents. When I disabled SSO Consent Management from the server and
> tested the client, the client worked fine.
> Now I am working on finding a way to give the user consents without the
> browser.
>
Currenty, Identity Server does not support managing consents for non
browser based authentications.

Thanks
Isura.

>
> [1]
> https://wiki.shibboleth.net/confluence/display/SHIB2/Contributions#Contributions-simplebash
>
> Thank you!
> Winma
>
>
> On Mon, Sep 3, 2018 at 10:57 PM Winma Heenatigala  wrote:
>
>>
>> Hi all,
>>
>> I am working on a project to implement SAML ECP profile for WSO2 IS.
>> Here is a brief summary on my project progress.
>>
>> *Introduction*
>> Web Based SSO profile supports for browser based clients to SSO.In
>> contrast SAML ECP(Enhanced Clients or Proxies) profile supports non-browser
>> based clients such as desktop clients to SSO.
>>
>> *Progress*
>> I researched on existing IDPs that has SAML ECP profile implemented.From
>> my research results I found that Shibboleth is the best  among the ECP
>> enabled  IDPs. As the initial step to the project I downloaded an existing
>> ECP client and connected it with Shibboleth to examined how the ECP client
>> works.
>>
>> During the discussion held today, we discussed about how the message flow
>> happens in the ECP. During the meeting we verified that although the SP
>> sends a set of IDP s in the Response message, the ECP actually choses the
>> IDP on its own and the client itself must validates whether the choosen IDP
>> is one of the IDPs accepted by the SP. We also discussed on the importance
>> of  having RelayState.
>>
>>
>> The following documents were written on connecting the ECP client with
>> Shibboleth.
>>
>> https://medium.com/@winma.15/installation-of-shibboleth-idp-in-ubuntu-3acc57075cad
>>
>> https://medium.com/@winma.15/shibboleth-sp-installation-in-ubuntu-d284b8d850da
>>
>> https://medium.com/@winma.15/connecting-ecp-with-shibboleth-using-wso2-identity-server-user-store-540f616ee968
>>
>> Thank you!
>> Winma
>>
>>
>> *Winma Heenatigala*
>> *Trainee Software Engineer | WSO2*
>>
>> *Mobile : +94719132444*
>>
>>
>>
>>
>
> --
>
> *Winma Heenatigala*
> *Trainee Software Engineer | WSO2*
>
> *Mobile : +94719132444*
>
>
>
>

-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][300][Store] Feature to change password of an user

[Isura Karunaratne]

On Thu, Sep 6, 2018 at 5:31 PM Vithursa Mahendrarajah 
wrote:

> Hi Dulanja,
>
> Please find my answers in-line:
>
> On Thu, Sep 6, 2018 at 10:45 AM Dulanja Liyanage  wrote:
>
>> Hi Vithursa,
>>
>> Few questions:
>>
>> 1. What happens when the user enters a wrong username? As a security best
>> practice, the returned message must not indicate that the username is
>> invalid. Because, a rogue user can determine valid usernames of the system
>> by using this feature (i.e. username harvesting). Therefore, for both valid
>> and invalid usernames, system should show a message similar to "A password
>> reset email has been sent to the registered email address".
>>
>
> As per current implementation, it returns message to indicate that the
> user name is invalid. I am agreeing with the point you mentioned, but on
> the other hand, it will not give a proper guide in situation like when user
> mistakenly enters their user name wrong.  I checked this feature in other
> accounts as well which indicate whether the user name is valid or not.
>
>>
>> 2. How are you storing the confirmation codes against the user? Is it as
>> a claim of the user or in the registry?
>>
>
> I hoped to store it as a claim of user (admin has access to confirmation
> code).
>
IMO this is not correct. Then the users who can view the user profiles of
others, can view the confirmation codes? Then they can change the passwords
of those users using those confirmation codes.



> 3. What is the validity of the confirmation code and how you plan to
>> cleanup the expired/used codes?
>>
>
> We can define it to be a day and store generated time along with the
> code.  Regarding the cleanup of used codes, once the user clicks on the
> link, gets verified and resets password. we can remove the confirmation
> code after successful reset. It won't be valid thereafter.
> Regarding the cleanup of expired codes,we do not need to remove expired
> codes as there will be one code per user, validating expiry of confirmation
> code would be enough. If it is necessary, we can do it by weekly scheduled
> task.
>
 Better to have a scheduled task, otheriwse the table will be grown if
users won't click on the email link.

>
> Also, to verify the confirmation code, we can have two options as:
>
>1. Send redirect link in mail (we have this in previous version)
>2. Send confirmation code (which user should enter to continue
>password reset, like in Facebook)
>
> Which one would be more feasible to have. Provide your thoughts.
>
In API wise there is no much difference between both options. We better to
support both options.


> Thanks,
> Vithursa
>

Thanks
Isura.

>
>> Thanks,
>> Dulanja
>>
>>
>> On Wed, Sep 5, 2018 at 11:02 PM, Vithursa Mahendrarajah <
>> vithu...@wso2.com> wrote:
>>
>>> [Update]
>>>
>>> Hi all,
>>>
>>> I have implemented UI changes to accommodate password reset feature.
>>> Forgot password option in login page [Img-1], requesting user name for
>>> validating the user [Img-2], redirection page [Img-3] and page to reset
>>> password [Img-4].
>>> In back end, I have implemented a MSF4J endpoint to validate the entered
>>> user name. Currently, I am implementing REST APIs in carbon-auth to
>>> generate random code (Using secureRandom [1]) and to send notifications
>>> with link to reset password.
>>>
>>> [1]
>>> https://docs.oracle.com/javase/7/docs/api/java/security/SecureRandom.html
>>>
>>> Thanks,
>>>
>>> On Thu, Aug 23, 2018 at 10:10 AM Ishara Cooray  wrote:
>>>
 +1 to make password-rest as the base path if we are not going to have
 any other apis other than password reset.

 since clicking on the url in the e-mail is something that is confirming
 the password reset action I would suggest to change the endpoint as 
 *confirm
 *than notify

 /initiate
> /confirm   -  endpoint gets called when user clicks on the link,
> validates the confirmation key
> /
>

 Hope we can use the same password-reset api for change password request
 as well.


 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Tue, Aug 21, 2018 at 5:43 PM, Sanjeewa Malalgoda 
 wrote:

>
>
> On Tue, Aug 21, 2018 at 5:31 PM Vithursa Mahendrarajah <
> vithu...@wso2.com> wrote:
>
>> Hi all,
>>
>> As per suggestions, I will work on reset password feature. Proposed
>> flow of implementation for this feature is as follows:
>>
>> [image: first_reset.png]  [image:
>> second_reset.png]
>>
>> We need following APIs to handle reset password request:
>> /password-reset-initiate  - generates a confirmation key
>> /password-reset-notify   -  endpoint gets called when user clicks on
>> the link, validates the confirmation key
>> /password-reset - end point to reset password, 

Re: [Architecture] Defining self-signup required/mandatory attributes using consent purposes PIIs.

[Isura Karunaratne]

On Fri, Jul 20, 2018 at 9:08 AM Hasintha Indrajee  wrote:
Hi Hasintha,

>
> On Thu, Jul 19, 2018 at 5:45 PM Hasintha Indrajee 
> wrote:
>
>> Current behavior of our self sign up page is getting user attributes
>> based on "required" and "mandatory" attributes which are defined against
>> claims. Also certain claims such as first name and last name are anyway
>> taken from the user who is getting registered irrespective of whether they
>> are marked as mandatory or required in respective claims. This seems
>> irrational in certain contexts.
>>
>> We don't have a good control over the attributes which we are getting
>> while self sign up. Secondly we don't have a proper way to validate with
>> purposes PII categories with user given attributes, because we have no
>> connection at all between these two sets.
>>
>> One of the ways to avoid this is, we can ask admins to configure required
>> and mandatory claims with whatever the PIIs defined under self sign up
>> purposes.
>>
>> Instead of that, what about getting required attributes for self sign up
>> from consent purposes defined for self registration under specific tenant
>> ?. Mandatory PIIs will be the mandatory user attributes while singing up.
>> The rationale behind this is, if the system stores a certain attribute of a
>> user other than the username and password, the system should get consent of
>> the user and also respective purposes should be shown to the user and
>> should have a valid consent for each attribute under respective purpose.
>> With this new approach, self registration attributes other than username
>> and password will be decided from purposes which are configured for
>> self-registration. With this, it makes sense and makes possible to validate
>> user input attributes with purposes and mandatory PIIs of purposes.
>> Additionally we have control over user attributes which we should gather
>> while self signing up without depending on claim configurations.
>>
>> In a case if someone doesn't want this new behavior, they can keep using
>> the old behavior. WDYT ?
>>
>
+1 for the approach.

There are three types of self signup stories.

   - No consents requires (No singup consents defined)
   - Consent uses only in SSO flows (No singup consents defined)
   - Consent uses in the signup flow

We need to use the exising signup claims in story 1 and 2.

Is this the same approach we are going to follow in JIT consents? There
might be attributes comming from the federated IDP which are not configured
in the JIT consents purposes.
How do we handle such cases? Are we going to skip those attributes?


Thanks
Isura.


>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453
>>
>>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453
>
>

-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Introducing New Claim Properties to Control Claims Shown in Different Views

[Isura Karunaratne]

Hi Johann,



On Wed, Jun 27, 2018 at 8:52 AM Johann Nallathamby  wrote:

> Hi IAM Team,
>
> I think the following limitation in the WSO2 IS is causing some major
> usability issues.
>
> We have following views mainly where we display claims for a user:
> 1. Admin user profile view in management console
> 2. My user profile view in user portal
> 3. Self sign-up view
>
> The way we select the claims shown in these views is based on a single
> property which is "supported by default". This means that we can't control
> the behavior of a claim individually for each of these views and causing
> some major usability issues. This also means that to get that experience
> users have to do JSP customization to the product which I think we can
> easily avoid. And when it comes to IDaaS, customization is not a choice.
>
> For example a claim like "Account Locked" has to be shown in "admin user
> profile" view, but not for "self sign-up" view or "my user profile" view.
> Also there can be a use case where I want to show minimal vital information
> on the self sign-up page to make it easier for the user to sign-up, but
> have an extensive profile view in the user portal.
>
> I faced these issues when trying to demo the product to customers, where
> when I want to show the self sign-up flow with email verification, I enable
> to "supported by default" property for "account locked" claim to show in
> the "admin user profile" view that the account is actually getting locked
> once the user signs up and until he confirms the email. But while doing
> that the claim also gets visible in the "self sign-up" view  that makes no
> sense.
>
> We in fact have the capability to configure properties for each claim from
> IS 5.3.0 onwards. This issue explained in this mail was actually one of the
> reasons we added this capability to IS 5.3.0, but later it got diluted due
> to IS 6.0.0 efforts. Can we introduce some new claim properties for the 3
> profiles above to control the visibility of the claims individually for
> each of these views?
>
> We can easily do this without breaking backward compatibility. Since these
> properties can be added through the claim management UI, we can even fix
> the existing product versions in this way. We can continue to use the
> "supported by default" property as the default property to fallback on if
> the relevant new property is not configured. But if a user explicitly
> configures this property we can use it. For the new versions we can ship
> these properties with default values we agree on (may be not for all
> claims, but the most important ones only, and for the rest the users can
> explicitly create the properties through the UI).
>

Thanks for bringing this up. We will add this capability in a future
release. [1]

[1] https://github.com/wso2/product-is/issues/3412

Thanks
Isura.



> Thanks and Regards,
> Johann.
>
> --
>
> *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*
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2 
*lean.enterprise.middleware*
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 Identity Server 5.6.0 RC3

[Isura Karunaratne]

Hi,

Tested followed scenarios in super tenant, primary user store.


   - Account Locking
   - Self Registration with email confirmation.
   - Self-care portal operations.
   - Password reset through a notification.
   - Password reset through challenge questions.
   - Account Recovery.
   - Password History validation.
   - Password Pattern validation.

No blocking issues found.

[+] Stable - Go ahead and release

Thanks
Isura.

On Tue, Jun 19, 2018 at 2:46 PM Dewni Weeraman  wrote:

> Hi,
>
> Tested below scenarios on IS 5.6.0-RC3 pack,
>
>- Invoke the OAuth Introspection Endpoint.
>- OAuth token revocation.
>- Entitlement policy creation using write policy in xml and publishing.
>- Using REST APIs via XACML to manage entitlement.
>- Create, update, get, delete an OAuth app using Dynamic Client
>Registration endpoint.
>
>
> No blocking issues found.
>
> [+] Stable - Go ahead and release
>
> Thanks,
> Dewni
>
> On Tue, Jun 19, 2018 at 1:43 PM, Sathya Bandara  wrote:
>
>> Hi all,
>>
>> I've tested following scenarios on the IS 5.6.0-RC3 pack.
>>
>> User management (add/update/remove users).
>> User management in secondary userstores (Read-Write LDAP).
>> Consent Management in SAML SSO.
>> SAML to SAML federation.
>> Creating workflows definitions for primary userstore users.
>> Engaging/Disabling workflows on user-store operations.
>> Enable role based authorization using XACML for service providers.
>> Tenant creation/update/disabling.
>>
>> No blocking issues are found.
>>
>> [+] Stable - go ahead and release.
>>
>> Thanks,
>> Sathya
>>
>>
>> On Tue, Jun 19, 2018 at 12:26 PM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> I've tested following scenarios on the IS 5.6.0-RC3 pack with default
>>> database setup.
>>>
>>>- Enable user self-registration and self-register a new user.
>>>- Add multiple consent purposes with multiple PII categories.
>>>- Login to dashboard and see whether we can see the default consent
>>>and above added PII categories.
>>>- Confirm claims are getting filtered based on consents.
>>>- Configure a service provider with OpenID Connect and acquire
>>>access tokens via Authorization Code, Implicit, Client Credential and
>>>Password grant types.
>>>- Enable ID token encryption for the service provider and test the
>>>flow with decryption for all grant types.
>>>- Delete the self-signed up user, create another user with the exact
>>>same username, log in to the dashboard and see what are the consents
>>>shown.
>>>- Revoke consents of the user via the dashboard and try accessing
>>>the SP to verify the consents are asked again.
>>>- Delete the SP, login to the dashboard and see whether the consents
>>>are deleted for that SP.
>>>
>>> No blocking issues are found.
>>>
>>> [+] Stable - go ahead and release.
>>>
>>> Thanks,
>>> Vihanga.
>>>
>>> On Fri, Jun 15, 2018 at 6:29 PM Madawa Soysa  wrote:
>>>
 Hi all,

 We are pleased to announce the third release candidate of WSO2 Identity
 Server 5.6.0.

 This release fixes the following issues

- 5.6.0-RC Fixes

- 5.6.0-Beta Fixes

- 5.6.0-Alpha2 Fixes

- 5.6.0-Alpha Fixes

- 5.6.0-M7 Fixes

- 5.6.0-M6 Fixes

- 5.6.0-M5 Fixes

- 5.6.0-M4 Fixes

- 5.6.0-M3 Fixes

- 5.6.0-M2 Fixes

- 5.6.0-M1 Fixes


 Source and distribution,
 Runtime -
 https://github.com/wso2/product-is/releases/tag/v5.6.0-rc3
 Analytics -
 https://github.com/wso2/analytics-is/releases/v5.6.0-rc3

 Please download, test the product and vote.

 [+] Stable - go ahead and release
 [-] Broken - do not release (explain why)

 Thanks,
 WSO2 Identity and Access Management Team
 --

 Madawa Soysa / Senior Software Engineer
 mada...@wso2.com / +94714616050

 *WSO2 Inc.*
 lean.enterprise.middleware

   




>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] 
>>>
>>> 

Re: [Architecture] [IAM] Consent Management with Requested Claims in Authentication Request

[Isura Karunaratne]

Hi Indunil,

On Sun, Mar 25, 2018 at 9:50 PM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
>
> Please find the following information on current implementation of consent
> management in IS 5.5.0.
>
>- Claims to populate in the consent page, will be retrieved from the
>claim mapping configuration in SP (i.e. claims which is configured as
>requested).
>- If the claims configured in SP are mentioned as mandatory (i.e.
>without those claims application cannot work), consent MUST be given by
>user, to proceed.
>- When user have provided the consent first time, consent receipt will
>be generated for that application and for that user. Then after consent
>page will be shown, if there are any more mandatory claims which user has
>not provided the consent to share with the application.
>- If there are no SP configurations, consider that as a federated
>scenario and populate all the authenticated user attributes as mandatory
>claims in the consent.
>
>
> Following is the suggested approach for handling consent management when
> the requested claims are send dynamically from the authentication request.
>
>- *Requested/Mandatory claims are only configured in SP*
>
>
>- Populate all the claims configured in SP, in the consent page.
>
>
>- *Requested/Mandatory claims are not configured in SP and requested
>in authentication request*
>
>
>- From framework, set all the requested attributes to the
>   authenticated user (i.e. values as null for the attributes which are not
>   available for the user) and set the required property of the claims to
>   true/false.
>
>
>- In the consent service, validate the required property and populate
>   the consent page. Since mandatory is a property which we have 
> introduced in
>   IS, that won't be affected for the requested claims in authentication
>   request.
>
>
>- All the requested claims in authentication request will be populated
>   in the consent page whether user have a attribute value or not.
>
>
>- We assume that all the user attributes for which the user consent is
>   needed, will be send in the first authentication request. For later
>   requests, consent page will not be shown. This is because, consent page
>   will be populated only for mandatory claims, if a consent receipt is
>   available for the user.
>
>
What is the expected bahavour if an addional claim is requiested in later
requests. (Not in the first request). In that case,I think we can popup
consent for that claim only.

Thanks
Isura.

>
>-
>
>
>- Filter out and remove the null user attribute values from framework
>   and send to the inbound component or can be handled null values in 
> inbound
>   component.
>
>
>- Federated claims will also be treated same way as above.
>
>
>- *Requested/Mandatory claims are configured in SP and requested in
>authentication request*
>
>
>- Populate all the claims configured in SP, in the consent page.
>
>
>- Here we will be not considering about the requested claims in the
>   request when showing the consent page.
>
>
> Appreciate your suggestions and comments on this.
>
> Thanks and Regards
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Emailindu...@wso2.com
> Mobile   0772182255
>



-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C4] Single location to configure Privacy and Security Policy URL

[Isura Karunaratne]

Hi Ruwan,

On Wed, Feb 21, 2018 at 3:28 PM, Ruwan Abeykoon  wrote:

> Hi All,
>
> In order to comply with GDPR regulations, we are planning to incorporate
> privacy and cookie policy URL configuration into carbon 4 "carbon.xml" .
> The following element will be added to "carbon.xml", as this needs to be
> available fr any product based on c4.
> This configuration will be disabled (commented out) by default, in which
> hard-coded URL shall be displayed by each UI.
>
> 
> 
> 
> 
> https://your.organozation/privacy/privacy-policy.html
>
>
Shouldn't this be a tenant wise configuration?

Thanks
Isura.

>
> 
> 
> https://your.organozation/privacy/cookie-policy.html
> 
>
>
> Furthermore, We will add following methods to "CarbonUtils.java" to access
> the above two properties. These methods may return null, in which, the
> relevant UI should render a default link for the respective policy URL.
>
> String getPrivacyPolicyURL()
> String getCookiePolicyURL()
>
>
> Cheers,
> Ruwan
>
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using REST APIs with Carbon console.

[Isura Karunaratne]

On Mon, Feb 19, 2018 at 7:46 AM, Harsha Thirimanna  wrote:

>
>
> On 13 Feb 2018 2:49 pm, "Menaka Jayawardena"  wrote:
>
> Hi all,
>
> I'm working on implementing the Retryable Outbound Provisioning for
> Identity Server. I have completed the backend implementation and now
> working on developing the UI.
>
> As per our initial discussion, the new UI was planned to be added to the
> IS carbon console. But when looking into this, I faced the following
> blocker.
>
> The backend services of the feature are exposed as REST APIs which need
> authorization header to be set.
> Authorization : Bearer Base64Encoded(username:password)
>
> But in carbon ui, we do not use rest APIs and we also could not authorize
> the rest request. So without developing a SOAP service, we could not use
> the existing rest API from the carbon ui.
>
>
>

> What exactly do you mean by 'couldn't use the existing rest API' ?
>

 IIUC, he is saying we don't have a way to authenticate to the rest API.

Management console does not use JSESSIONID cookie to authenticate when
local transport is using.


local:/${carbon.context}/services/




Regards,
Isura.

>
>
>
> I also looked at the IS dashboard. But there also, we have used only SOAP
> APIs.
>
> Is there a method to use this without writing a WSDL for current identity
> server version?
>
> Thanks and Regards,
> Menaka
>
> --
> *Menaka Jayawardena*
> *Software Engineer - WSO2 Inc*
> *Tel : 071 350 5470*
> *LinkedIn: https://lk.linkedin.com/in/menakajayawardena
> *
> *Blog: https://menakamadushanka.wordpress.com/
> *
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Isura Karunaratne]

Hi Chiran,

Please find the inline comments.

1)


POST/dialects/{id}

Add New Claim Dialect.
The context for the posting a dialect should be like bellow.


POST/dialects

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


2)



DELETE/dialect/{id}

Delete Claim Dialect
Delete claim dialect should be like bellow

DELETE/dialects/{id}

Delete Claim Dialect


3)


GET/dialect

Get Available Claim Dialects

Get Available Claim Dialects should be as follows.


GET/dialects

Get Available Claim Dialects


4)


PUT/dialect

Update existing claim dialect.

Update existing claim dialect should be as follows,

PUT/dialects/{id}

Update existing claim dialect.



5)


PUT/dialects/{id}/claims

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

Delete external Claim

Update and delete External claims should be as follows


PUT/dialects/{dialect-id}/claims/{claim-id}

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

Delete external Claim







PUT/attributes

Update a Local Claim.

Update a Local Claim should be as follows


PUT/attributes/{local-claim-id}

Update a Local Claim.


Thanks
Isura.



On Fri, Feb 9, 2018 at 5:30 PM, Chiran Wijesekara  wrote:

> Hi all,
>
> Please find the attached the link[1] to the swagger file of the REST API
> design.
> Would be glad to have your thoughts and feedback.
>
> [1] https://app.swaggerhub.com/apis/chirankavinda123/claim_
> management_service_endpoint/1.0.0
> Thanks.
>
>
> On Thu, Feb 8, 2018 at 10:37 AM, Chiran Wijesekara 
> wrote:
>
>> 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] 
>>
>
>
>
> --
> *Chiran Wijesekara*
>
>
> *Software Engineering Intern | WSO2*Email: chir...@wso2.com
> Mobile: +94712990173web: www.wso2.com
>
> [image: https://wso2.com/signature] 
>



-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generalizing Post Authentictaion Handling in Authentictaion Framework.

[Isura Karunaratne]

On Fri, Feb 2, 2018 at 10:07 AM, Hasintha Indrajee <hasin...@wso2.com>
wrote:

>
> On Fri, Feb 2, 2018 at 8:00 AM, Isura Karunaratne <is...@wso2.com> wrote:
>
>>
>>
>> On Thu, Feb 1, 2018 at 1:41 PM, Hasintha Indrajee <hasin...@wso2.com>
>> wrote:
>>
>>> Eventing is more asynchronous. We may need synchronous processing for
>>> this. Also we need to control the flow of these handlers depending on the
>>> state of the handler. ex - we may need to do few redirections within a
>>> handler in order to proceed (eg - missing mandatory claim handler.). Hence
>>> I think it's better to go with a specific interface than our handler
>>> architecture.
>>>
>>
>> Eventing can be synchronous as well. Since we need to handle
>> redirections +1 to go with a specfic interface design.
>>
> Our current eventing framework does not have synchronous support AFAIK
>
It can be sync or assync depending on the handler implemenation. [1]

[1]
https://github.com/wso2/carbon-identity-framework/blob/master/components/identity-event/org.wso2.carbon.identity.event/src/main/java/org/wso2/carbon/identity/event/services/IdentityEventServiceImpl.java#L56

Thanks
Isura.

>
>> Thanks
>> Isura.
>>
>>>
>>> On Thu, Feb 1, 2018 at 1:36 PM, Malithi Edirisinghe <malit...@wso2.com>
>>> wrote:
>>>
>>>> Hi Hasintha,
>>>>
>>>> Does this mean that you will be introducing another OSGi service
>>>> interface for post authentication handlers.
>>>> What about using the already available eventing service [1].
>>>>
>>>> [1] https://github.com/wso2/carbon-identity-framework/blob/m
>>>> aster/components/identity-event/org.wso2.carbon.identity.eve
>>>> nt/src/main/java/org/wso2/carbon/identity/event/services/
>>>> IdentityEventService.java
>>>>
>>>> Thanks,
>>>> Malithi.
>>>>
>>>> On Thu, Feb 1, 2018 at 6:20 AM, Hasintha Indrajee <hasin...@wso2.com>
>>>> wrote:
>>>>
>>>>> At the present we have post authentication criteria which are
>>>>> evaluated upon authentication in an authentication flow. Examples are
>>>>> "Handling missing mandatory claims" and "Authorization handling". 
>>>>> According
>>>>> to the current implementation these logics are bind towards our framework
>>>>> implementation so that if we need to add a new post authentication
>>>>> evaluation criteria, we do not have an alternative other than changing
>>>>> framework source.
>>>>>
>>>>> With emerging requirements we may need to add more post authentication
>>>>> criteria in the future. For an example, we may need to intercept post
>>>>> authentication and request for consent on requested claims. Likewise there
>>>>> may be other requirements to intercept post authentication flow.
>>>>>
>>>>> Foreseeing these requirements we are planing to generalize post
>>>>> authentication handling so that post authentication handling will no 
>>>>> longer
>>>>> be a static part of framework. We should be able to add post 
>>>>> authentication
>>>>> handlers as OSGI services. Upon this change, missing mandatory claim
>>>>> handler and authorization handler will be two OSGI post authentication
>>>>> handlers.
>>>>>
>>>>> --
>>>>> Hasintha Indrajee
>>>>> WSO2, Inc.
>>>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Malithi Edirisinghe*
>>>> Associate Technical Lead
>>>> WSO2 Inc.
>>>>
>>>> Mobile : +94 (0) 718176807
>>>> malit...@wso2.com
>>>>
>>>
>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>
>>
>> --
>>
>> *Isura Dilhara Karunaratne*
>> Associate Technical Lead | WSO2
>> Email: is...@wso2.com
>> Mob : +94 772 254 810 <077%20225%204810>
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generalizing Post Authentictaion Handling in Authentictaion Framework.

[Isura Karunaratne]

On Thu, Feb 1, 2018 at 1:41 PM, Hasintha Indrajee  wrote:

> Eventing is more asynchronous. We may need synchronous processing for
> this. Also we need to control the flow of these handlers depending on the
> state of the handler. ex - we may need to do few redirections within a
> handler in order to proceed (eg - missing mandatory claim handler.). Hence
> I think it's better to go with a specific interface than our handler
> architecture.
>

Eventing can be synchronous as well. Since we need to handle redirections
+1 to go with a specfic interface design.

Thanks
Isura.

>
> On Thu, Feb 1, 2018 at 1:36 PM, Malithi Edirisinghe 
> wrote:
>
>> Hi Hasintha,
>>
>> Does this mean that you will be introducing another OSGi service
>> interface for post authentication handlers.
>> What about using the already available eventing service [1].
>>
>> [1] https://github.com/wso2/carbon-identity-framework/blob/
>> master/components/identity-event/org.wso2.carbon.
>> identity.event/src/main/java/org/wso2/carbon/identity/
>> event/services/IdentityEventService.java
>>
>> Thanks,
>> Malithi.
>>
>> On Thu, Feb 1, 2018 at 6:20 AM, Hasintha Indrajee 
>> wrote:
>>
>>> At the present we have post authentication criteria which are evaluated
>>> upon authentication in an authentication flow. Examples are "Handling
>>> missing mandatory claims" and "Authorization handling". According to the
>>> current implementation these logics are bind towards our framework
>>> implementation so that if we need to add a new post authentication
>>> evaluation criteria, we do not have an alternative other than changing
>>> framework source.
>>>
>>> With emerging requirements we may need to add more post authentication
>>> criteria in the future. For an example, we may need to intercept post
>>> authentication and request for consent on requested claims. Likewise there
>>> may be other requirements to intercept post authentication flow.
>>>
>>> Foreseeing these requirements we are planing to generalize post
>>> authentication handling so that post authentication handling will no longer
>>> be a static part of framework. We should be able to add post authentication
>>> handlers as OSGI services. Upon this change, missing mandatory claim
>>> handler and authorization handler will be two OSGI post authentication
>>> handlers.
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>
>>
>> --
>>
>> *Malithi Edirisinghe*
>> Associate Technical Lead
>> WSO2 Inc.
>>
>> Mobile : +94 (0) 718176807
>> malit...@wso2.com
>>
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Consent Management APIs for IS 5.5.0

[Isura Karunaratne]

On Thu, Feb 1, 2018 at 7:21 PM, Ayesha Dissanayaka <aye...@wso2.com> wrote:

>
> Hi,
>
> We have started evaluating effort on providing a UI in Identity Server
> dashboard for consent management and came acrossr followings.
>
> *GET /consents*
>
>- Need to return user friendly "Service Name" and "Service Description"
>- *purpose* object need *purposeId*.
>- *piiCategory* object should contain *piiCategoryId* and
>*piiCategoryName*. remove duplicated *piiCategory.*
>   - Sample response is suggested as below.
>
>
Will incorporate these changes.

>
>-
>
>
>   ...
>   "purposes": [
>   {
> "purpose": "string",  *"purposeId": "string",*
> "purposeCategory": [
>   "string"
> ],
> "consentType": "string",
> "piiCategory": [
>   {
> "piiCategoryName": "string",  
> "piiCategoryId": "string",
> "validity": "string"
>   }
> ],
>   ...
>
>   -
>
> Also I have observed that *piiCategory* is refered as *piiCategory* and
> *piiCategories* in different API responses. Is it the intended naming?
>

Since it is a list, it should be reffered as piiCategeries, but we
used *piiCategory in
consent receipt *to comply with the spec.

Thanks
Isura.

>
> Thanks!
> -Ayesha
>
>
> On Thu, Feb 1, 2018 at 6:27 PM, Darshana Gunawardana <darsh...@wso2.com>
> wrote:
>
>> On Thu, Feb 1, 2018 at 6:18 PM, Omindu Rathnaweera <omi...@wso2.com>
>> wrote:
>>
>>> Hi Darshana,
>>>
>>> On Thu, Feb 1, 2018 at 5:42 PM, Darshana Gunawardana <darsh...@wso2.com>
>>> wrote:
>>>
>>>>
>>>> On Thu, Feb 1, 2018 at 5:13 PM, Isura Karunaratne <is...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Darshana,
>>>>>
>>>>> On Thu, Feb 1, 2018 at 3:39 PM, Darshana Gunawardana <
>>>>> darsh...@wso2.com> wrote:
>>>>>
>>>>>> Hi Isura,
>>>>>>
>>>>>> How these concents are handled with state changes of related entities?
>>>>>>
>>>>>> For example,
>>>>>> > user delete
>>>>>> > sp delete
>>>>>>
>>>>>> This should be handled through a user operation event listener or
>>>>> event handler.
>>>>>
>>>>
>>>> Yes. So are we going to have relavent implementations with this feature?
>>>>
>>>
>>> As the API is not specific to a product these scenarios should be
>>> handled as a part of integrating the feature to the product.  We will
>>> handle these cases during the integration effort for product IS.
>>>
>>
>> That makes sense.. +1 for the approach.
>>
>>>
>>>
>>>>
>>>> Can there be any other cases similar to above?
>>>>
>>>
>>> Apart from the above scenarios, user store removal and tenant
>>> deactivation are 2 such cases. However, revoking consents for tenant
>>> deactivation is something we have to think a bit more as we can reactivate
>>> the tenants and once that it done, the consents will no longer be active.
>>>
>>>>
>>>> Thanks,
>>>>
>>>>> Isura.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> On Wed, Jan 10, 2018 at 1:58 PM, Isura Karunaratne <is...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Jan 10, 2018 at 12:44 PM, Godwin Shrimal <god...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Isuru,
>>>>>>>>
>>>>>>>> Please see below few suggestions.
>>>>>>>>
>>>>>>>> 1. API name of the Purpose Category (/pcategories) is not readable.
>>>>>>>> Why don't we use it as */**purpose-categories* ?
>>>>>>>> 2. What is /*category*/{purposeCategoryId}  API ? It shows API
>>>>>>>> name as /*category. *I think it should be renamed as below
>>>>>>>> (Ac

Re: [Architecture] [RRT] [IAM] Hash code, access token, refresh token and client secret values before store them in the database

[Isura Karunaratne]

On Mon, Jan 29, 2018 at 1:10 PM, Dimuthu Leelarathne 
wrote:

> Hi Nuwan,
>
> On Mon, Jan 29, 2018 at 1:08 PM, Nuwan Dias  wrote:
>
>> Hi Dimuthu,
>>
>> I don't think we can regenerate since the client-secret will be hashed
>> too. So I think we have to completely disable showing the test token and
>> remove it off from the Swagger Console as well.
>>
> Can't we use clientId to regrenate client secret.

Thanks
Isura.

>
>> Yes. Or we can get it as input.
>
>
>> We may also have to think of providing a mechanism to renew the
>> client-secret if/when lost.
>>
>
> I meant regnerate client secret itself, not the access token.
>
> thanks,
> Dimuthu
>
>
>>
>> Thanks,
>> NuwanD.
>>
>>
>>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Personal information export API

[Isura Karunaratne]

On Mon, Jan 22, 2018 at 5:25 PM, Omindu Rathnaweera  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 search criteria. If you
> need to include receipt data of all the consent entries, you will have to
> iterate through all the consent IDs and fetch the individual receipts. Keep
> in mind that this will likely to generate a payload of a considerable size.
>

Yes. The payload will be high, if we are sending the whole receipts.

Is it mandatory to send the response synchronously? Shall we have an option
to send the response offline via email too?

Thanks
Isura

>
> Regards,
> Omindu.
>
>
> On Mon, Jan 22, 2018 at 5:12 PM, Maduranga Siriwardena  > wrote:
>
>> Hi all,
>>
>> We are creating a REST API to export user information for IS 5.5.0.
>>
>> Swagger at [1] is the initial design of the API.
>>
>> In the initial phase we are allowing the data to be exported only by the
>> owner of the profile.
>>
>> At the moment we are planing to export basic user profile information and
>> the consents user has given. Response JSON has 2 parts in it.
>>
>>- basic: this part will have the users profile information (claims)
>>in wso2 dialect
>>- consents: this part will have an array of consents user has
>>provided to the Identity Server. Though in the swagger it is represented
>>with the ID of the consent receipt, the actual response will consist of 
>> the
>>whole consent receipt. (Refer mail thread [2] @ architecture@wso2.org
>>for more information)
>>
>> Below is a sample JSON response.
>>
>> {
>>   "basic": {
>> "http://wso2.org/claims/userid": "92d6513e-f4ca-4438-b403-98380
>> 695ed08",
>> "http://wso2.org/claims/username": "maduranga",
>> "http://wso2.org/claims/givenname": "Maduranga",
>> "http://wso2.org/claims/lastname": "Siriwardena",
>> "http://wso2.org/claims/emailaddress": "madura...@wso2.com",
>> "http://wso2.org/claims/telephone": "+947
>> <+94%2071%20111%20>"
>>   },
>>   "consents": [
>> {
>>   "id": "bc53e7bd-013d-4020-b522-1915ada1f305"
>> }
>>   ]
>> }
>>
>> Do you have any suggestions for additional types of information to be
>> included in the response?
>>
>> [1] https://app.swaggerhub.com/apis/Maduranga/PersonalInform
>> ationExport/1.0.0
>> [2] Consent Management APIs for IS 5.5.0
>>
>> Thanks,
>>
>> --
>> Maduranga Siriwardena
>> Senior Software Engineer
>> WSO2 Inc; http://wso2.com/
>>
>> Email: madura...@wso2.com
>> Mobile: +94718990591 <+94%2071%20899%200591>
>> Blog: *https://madurangasiriwardena.wordpress.com/
>> *
>> 
>>
>
>
>
> --
> Omindu Rathnaweera
> Senior Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>



-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Decoupling Client Authentication from OAuth2 Flow

[Isura Karunaratne]

On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee  wrote:

> The idea behind this is to decouple the authentication mechanism used by
> OAuth2 clients from the rest of the OAuth2 logic, so that different types
> of client authenticators can be plugged. For an example according to
> specification [1] client_secret_basic, client_secret_post,
> client_secret_jwt are few client authentication mechanisms.
>
> The client authentication will be done through an extension. Hence
> different client authentication criteria can be implemented and can be
> plugged.
>
> The interface (API) will consist of three main methods.
>
> 1) canAuthenticate - Decides whether the particular authenticator can
> authenticate the incoming request or not.
>
> 2) authenticateClient - Authenticates the client request based on
> information present. As a result of authentication client ID will be
> available in the context.
>
> 3) getClientId - Depending on the authentication mechanism they way client
> ID is extracted depends. For an example in JWT client authentication client
> sends out the client Id within the JWT as the subject. Hence in a case
> authenticaiton fails, we may need to extract client Id for other puposes.
> ex - data publishing, if the client is non confidential.
>
> The client authenticator has to be implemented as an OSGI bundle and
> should be deployed in dropins upon building. Also relevant authenticator
> name has to be configured in identity.xml under client authenticators.
>
> 
>
>  ClientAuthHandler>
>
> 
>

How are we going to support, non-confidentials clients, will that support
through another ClientAuthHandler? Also, Do we support backword compatibity
for exsting ClientAuthHandlers?


Thanks
Isura
>
>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli
> entAuthentication
> 
>
>
>
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <077%20189%202453>
>
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0

[Isura Karunaratne]

Hi Hasanthi,

On Thu, Jan 4, 2018 at 4:32 PM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi All,
>
> Following tasks are identified for the implementation for the $subject.
>
> 1. Move the logic of validating the token API invocation request to
> validate required parameters for JWT client authentication to
> PrivatekeyJWTClientAuthHandler
> 2. Introduce a new interface to read the public certificate.
>- Certificate can be read from keystore
>- Certificate can be read from db
>- Certificate can be read from any other means
> 3. Data which will be persisted in IDN_JWT_PRIVATE_KEY can be grown
> rapidly which may cause to some performance issues. So need to implement a
> cleanup script based on the expiration time of the JWT.
>

Which data are supposed to store in  IDN_JWT_PRIVATE_KEY table? What is the
reason to store those data?

Thanks
Isura.

> 4. Honour the UI configuration for confidential applications which is
> discussed in mail [1]
>
> Apart from above need to consider on following tasks:
> 1. Improving the unit tests of the repository
> 2. Improve the documentations for the $subject.
>
>
> [1] Confidential Aplications in OAuth2 Flow
>
> Thanks,
> --
>
> Hasanthi Dissanayake
>
> Senior Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>



-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Isura Karunaratne]

Repo name for outbound connector

   - * identity-outbound-provisioning-scim2*

Repo name for the scim2 client.

   -
* identity-client-scim2 *


@isuraranga,

Why do we need the scim2-commons repo? Can't we use Charon for that?

Thanks
Isura.

On Mon, Nov 20, 2017 at 3:04 PM, Afkham Azeez  wrote:

> What is the repo name?
>
> On Tue, Nov 7, 2017 at 1:06 PM, Maheshika Goonetilleke  > wrote:
>
>> Hi Azeez
>>
>> Please confirm.
>>
>> On Tue, Nov 7, 2017 at 11:23 AM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Maheshika,
>>>
>>> Can we have following 3 repos for this project under wso2-extensions
>>> organization?
>>>
>>> 1. *identity-outbound-provisioning-scim2*
>>>
>>> For the outbound connector
>>>
>>> 2. *identity-scim2-common*
>>>
>>> For common utilities for inbound and outbound connectors. E.g.
>>> AttributeMapper class in inbound connector which is needed for outbound
>>> connector as well.
>>>
>>> 3. *identity-client-scim2*
>>>
>>> For SCIM2 client generated using SCIM2 swagger files. This will be used
>>> by outbound connector as well as can be used by anyone as standalone
>>> client. Ideally this should be used for the scim2 compliance test suite as
>>> well, but have failed to do so.
>>>
>>> Regards,
>>> Johann.
>>>
>>> On Mon, Oct 16, 2017 at 2:21 PM, Johann Nallathamby 
>>> wrote:
>>>
 Yes, I also think we need to take the approach of using the Swagger
 files and generate SDK because that is what standard Rest API world will be
 doing. We can find any issues early.

 Regards,
 Johann.

 On Mon, Oct 16, 2017 at 2:18 PM, Gayan Gunawardana 
 wrote:

>
>
> On Mon, Oct 16, 2017 at 1:21 PM, Isuranga Perera <
> isurangamper...@gmail.com> wrote:
>
>> Hi Gayan,
>>
>> In that case, I'll try to create an SDK from swagger and use it as
>> the client.
>>
> That would be great.
>
>>
>> Best Regards
>>
>> On Mon, Oct 16, 2017 at 9:12 AM, Gayan Gunawardana 
>> wrote:
>>
>>> Since you are looking for abstraction layer, can implement something
>>> like [1] for SCIM2 as well.
>>>
>>> [1] https://github.com/wso2-extensions/identity-inbound-provisio
>>> ning-scim/blob/master/components/org.wso2.carbon.identity.sc
>>> im.common/src/main/java/org/wso2/carbon/identity/scim/common
>>> /impl/ProvisioningClient.java
>>>
>>> On Sun, Oct 15, 2017 at 11:16 PM, Gayan Gunawardana 
>>> wrote:
>>>


 On Sun, Oct 15, 2017 at 8:39 PM, Johann Nallathamby <
 joh...@wso2.com> wrote:

> *[+ IsharaK, Omindu, Farasath]*
>
> On Sun, Oct 15, 2017 at 7:34 PM, Isuranga Perera <
> isurangamper...@gmail.com> wrote:
>
>> Hi,
>>
>> I went through the scim2-compliance-test-suite [1] source code,
>> but I couldn't find an abstraction layer which separates the SCIM 2 
>> client
>> from the test and report modules. Is there any way I can separate 
>> SCIM 2.0
>> client from [1] so that I can use it as the SCIM 2.0 client for the
>> $subject.
>>
> There is no clear abstraction layer. Both SCIM2 compliance test
 developed by Vindula and SCIM 1.1 outbound provisioning connector are
 utilized apache commons http client .

>
>> In addition to that, I found this[2] repository which contains
>> another SCIM client. can I know the completion level of this project?
>>
> This is feign http client and Vindula found it hard to use.

>
>> In summary, there are 3 options which I can use to generate a
>> SCIM 2.0 client.
>>
> Most feasible way is to go with apache commons HttpClient  but
 better to give a try with swagger doc as well.

>
>>
>>1. Separate SCIM 2.0 client from [1]
>>2. Separate SCIM 2.0 client from [2]
>>3. Use swagger doc [3] to generate client
>>
>>
>> [1] https://github.com/wso2-incubator/scim2-compliance-test-suite
>> [2] https://github.com/HansageeSJ/scim-client
>> [3] https://wso2.org/jira/browse/IDENTITY-5695
>>
>> Appreciate any suggestions.
>>
>>
>> Best Regards
>> Isuranga Perera
>>
>> On Fri, Oct 13, 2017 at 9:42 AM, Gayan Gunawardana <
>> ga...@wso2.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 12, 2017 at 5:33 PM, Johann Nallathamby <
>>> joh...@wso2.com> wrote:
>>>


 On Thu, Oct 12, 2017 at 1:28 PM, Isuranga Perera <
 isurangamper...@gmail.com> wrote:

> Hi IAM Team,
>

Re: [Architecture] Self Contained Access Tokens in IS 5.4.0

[Isura Karunaratne]

On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne <is...@wso2.com> wrote:

> Hi all,
>
> Currently, ACCESS_TOKEN column length is defined as 512 [1] which is not
> enough to store self-contained access token [2].
>
> Shall we increase the column size by default?
>
> Thanks
> Isura.
>
>
> [1]
> CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN (
> TOKEN_ID VARCHAR (255),
> ACCESS_TOKEN VARCHAR(512),
> REFRESH_TOKEN VARCHAR(512),
> CONSUMER_KEY_ID INTEGER,
> AUTHZ_USER VARCHAR (100),
> TENANT_ID INTEGER,
> USER_DOMAIN VARCHAR(50),
> USER_TYPE VARCHAR (25),
> GRANT_TYPE VARCHAR (50),
> TIME_CREATED TIMESTAMP DEFAULT 0,
> REFRESH_TOKEN_TIME_CREATED TIMESTAMP DEFAULT 0,
> VALIDITY_PERIOD BIGINT,
> REFRESH_TOKEN_VALIDITY_PERIOD BIGINT,
> TOKEN_SCOPE_HASH VARCHAR(32),
> TOKEN_STATE VARCHAR(25) DEFAULT 'ACTIVE',
> TOKEN_STATE_ID VARCHAR (128) DEFAULT 'NONE',
> SUBJECT_IDENTIFIER VARCHAR(255),
> PRIMARY KEY (TOKEN_ID),
> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES
> IDN_OAUTH_CONSUMER_APPS(ID) ON DELETE CASCADE,
> CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,
> TENANT_ID,USER_DOMAIN,USER_TYPE,TOKEN_SCOPE_HASH,
>TOKEN_STATE,TOKEN_STATE_ID)
>
>
> [2] https://wso2.org/jira/browse/IDENTITY-6917
>
>
> --
>
> *Isura Dilhara Karunaratne*
> Associate Technical Lead | WSO2
> Email: is...@wso2.com
> Mob : +94 772 254 810 <+94%2077%20225%204810>
> Blog : http://isurad.blogspot.com/
>
>
>
>


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Self Contained Access Tokens in IS 5.4.0

[Isura Karunaratne]

Hi all,

Currently, ACCESS_TOKEN column length is defined as 512 [1] which is not
enough to store self-contained access token [2].

Shall we increase the column size by default?

Thanks
Isura.


[1]
CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN (
TOKEN_ID VARCHAR (255),
ACCESS_TOKEN VARCHAR(512),
REFRESH_TOKEN VARCHAR(512),
CONSUMER_KEY_ID INTEGER,
AUTHZ_USER VARCHAR (100),
TENANT_ID INTEGER,
USER_DOMAIN VARCHAR(50),
USER_TYPE VARCHAR (25),
GRANT_TYPE VARCHAR (50),
TIME_CREATED TIMESTAMP DEFAULT 0,
REFRESH_TOKEN_TIME_CREATED TIMESTAMP DEFAULT 0,
VALIDITY_PERIOD BIGINT,
REFRESH_TOKEN_VALIDITY_PERIOD BIGINT,
TOKEN_SCOPE_HASH VARCHAR(32),
TOKEN_STATE VARCHAR(25) DEFAULT 'ACTIVE',
TOKEN_STATE_ID VARCHAR (128) DEFAULT 'NONE',
SUBJECT_IDENTIFIER VARCHAR(255),
PRIMARY KEY (TOKEN_ID),
FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES
IDN_OAUTH_CONSUMER_APPS(ID) ON DELETE CASCADE,
CONSTRAINT CON_APP_KEY UNIQUE
(CONSUMER_KEY_ID,AUTHZ_USER,TENANT_ID,USER_DOMAIN,USER_TYPE,TOKEN_SCOPE_HASH,
   TOKEN_STATE,TOKEN_STATE_ID)


[2] https://wso2.org/jira/browse/IDENTITY-6917


-- 

*Isura Dilhara Karunaratne*
Associate Technical Lead | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] SCIM Support for Admin Users

[Isura Karunaratne]

Hi Sathya,

On Thu, Jul 20, 2017 at 2:34 PM, Sathya Bandara  wrote:

> Hi all,
>
> With the current user core implementation we do not include a SCIM user_id
> for admin users (Since SCIM is not used in all products) which prevents
> SCIM based CRUD operations on admin users. In order to implement this we
> have identified the following two approaches.
>
> *#option 1*
>
> Generate admin users' SCIM userId in SCIM component activator at server
> start up (for admin users in super tenant domain). For tenant admins we can
> configure a listener on tenant admin creation in TenantMgtService[2] to
> generate user_id if SCIM is enabled.
>

+1 to this approach. For tenant admins, we can create a TenantMgtListener
and use onTenantCreate operation to create SCIM ID.

With the SCIM ID, it is required add following claims as well


   -

   urn:scim:schemas:core:1.0:meta.created

   -

   urn:scim:schemas:core:1.0:meta.lastModified

   -

   urn:scim:schemas:core:1.0:userName



Thanks
Isura.

> *#option 2*
>
> In AbstractUserStoreManager [1] modify addInitialAdminData() operation to
> apply SCIM user_id claim when adding a new admin user. For the default LDAP
> admin we can check the already existing claims for the user_id claim and
> generate a random id if it doesn't exist. For tenant admins this can be
> done via the above mentioned listener. In this approach we expose SCIM on
> all the other products which do not support SCIM since we implement this at
> kernel level.
>
> In my opinion, option 1 would be more suitable since in this approach we
> do not need to additionally provide this feature on products that do not
> support SCIM.
>
> Highly appreciate your suggestions on this.
>
> [1] https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.
> wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/
> core/common/AbstractUserStoreManager.java#L3835
> [2] https://github.com/wso2/carbon-multitenancy/blob/master/
> components/tenant-mgt/org.wso2.carbon.tenant.mgt/src/
> main/java/org/wso2/carbon/tenant/mgt/services/TenantMgtAdmin
> Service.java#L57
>
>
> Thanks,
> Sathya
> --
> Sathya Bandara
> Software Engineer
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>
> <+94%2071%20411%205032>
>



-- 

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

[Isura Karunaratne]

On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara 
wrote:

> Hi Indunil,
>
> A few more details.
>
> On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara 
> wrote:
>
>> Hi Indunil,
>>
>> Please see my comments inline.
>>
>> On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <
>> indu...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> Thanks all of your valuable feedbacks. Currently we are implementing
>>> following REST endpoints. We have modeled the the rest API using swagger
>>> and you can find the attached swagger definition as well. Really appreciate
>>> your comments and suggestions on the specified endpoints, please mention if
>>> there are other required endpoints.
>>>
>>>
>>> Endpoint Method Usage Request Body Response
>>> /scopes POST Create Scopes [{"key": "openid", "name": "openid",
>>> "description": "openid scope", "bindings": ["role1", "role2"]}] "HTTP/1.1
>>> 201 Created"
>>>
>>
>> Here the request body is a json array. Does that mean we can create
>> multiple scopes at once? If not, let's get rid of wrappering squire
>> brackets.
>>
>
> My +1 is to have multiple scopes in the request.
>
>
>>
>>
>>>
>>> DELETE Delete Scopes ["key1", "key2"] "HTTP/1.1 201 Deleted"
>>>
>>> PUT Update Scopes [{"key": "openid", "name": "openid", "description":
>>> "openid scope", "bindings": ["role3"]}] "HTTP/1.1 201 Updated"
>>>
>>
>> In these 2 cases the status code should be 200. (We may also use 204 for
>> delete like DCRM spec does.)
>>
>
>

> From the http spec https://tools.ietf.org/html/rfc2616#section-9.7 :
>
>  A successful response SHOULD be 200 (OK) if the response includes an
>entity describing the status, 202 (Accepted) if the action has not
>yet been enacted, or 204 (No Content) if the action has been enacted
>but the response does not include an entity.
>
>
> So you can choose between 200 or 204 depending on the response body you
> send back.
>
> Further, instead of sending a request body in the DELETE request (which is
> not restricted by the spec though), we can send it like this.
>
>  DELETE /scopes?keys=key1,key2
 WDYT?

+1.
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.


>
> Thanks,
> Bhathiya
>
>
>>
>>
>>> /scopes?filter=maxResults+Eq+100 GET Get all available Scopes
>>> [{"key": "openid", "name": "openid", "description": "openid scope",
>>> "bindings": []}]
>>>
>>> /scopes/by-bindings GET Get Scopes by Binding/s {"bindings": ["role1",
>>> "role2"]} [{"key": "openid", "name": "openid", "description": "openid
>>> scope", "bindings": ["role1", "role2"]}]
>>>
>>
>> This should be a POST if you have a request body. Instead of that, how
>> about something like this?
>>
>> /scopes?bindings=role1,role2
>>
>>
>>>
>>> /scopes/keys GET Get all the available
>>> Scope Keys
>>> ["key1", "key2"]
>>>
>>> /scopes/keys/by-bindings GET Get Scope keys
>>> by Binding/s {"bindings": ["role1", "role2"]} ["key1", "key2"]
>>>
>>
>> We can do the same here.
>>
>> /scopes/keys?bindings=role1,role2
>>
>>
>>>
>>> /scopes/{scope_key} GET Get a Scope by Scope Key
>>> {"key": "openid", "name": "openid", "description": "openid scope",
>>> "bindings": []}
>>>
>>> DELETE Delete a Scope by
>>> Scope Key
>>> "HTTP/1.1 201 Deleted"
>>>
>>> PUT Update a Scope by
>>> Scope Key {"key": "openid", "name": "openid", "description": "openid
>>> scope", "bindings": ["role3", "role4"]} "HTTP/1.1 201 Updated"
>>>
>>
>> Need to change the status codes as suggested above.
>>
>> Thanks,
>> Bhathiya
>>
>>
>>>
>>>
>>> @Nuwan: We have a suggestion to modified the database schema as follows
>>> to properly store bindings (considering the performance issues in using
>>> comma separated values and renaming the "ROLES" field to a generic name),
>>> but need to discuss about this and finalize.
>>>
>>>
>>> ​
>>> Appreciate your comments and suggestions and I will arrange a meeting
>>> tomorrow to have a further discussion on this.
>>>
>>> Thanks and Regards
>>>
>>>
>>> On Mon, Jun 12, 2017 at 2:53 AM, Nuwan Dias  wrote:
>>>

 On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <
 indu...@wso2.com> wrote:

> Hi,
>
> We are currently working on implementing following features which are
> needed for APIM 3.0. You can find the initial discussion details in [1].
>
>1. Sign UserInfo JWT response
>2. Scope registration and Scope binding
>3. DCRM
>
>
> *Sign UserInfo JWT response:*
> JWT user info response signing implementation is in [1].
>
> Currently in APIM, there is a key manager global wise configuration to
> configure needed claims which needed to be send in user info response. We
> need to consider, when no SP wise requested claims are configured as in
> APIM, whether we need to send all the claims bound for a specific scope in
> oidc-scope-config.xml.
> Currently in IS, we are sending only those claims which are common in
> both OIDC 

Re: [Architecture] [Dev][IS][APIM] Providing a SCIM Id for admin user in SCIM

[Isura Karunaratne]

Hi Tharika,

On Mon, Jun 12, 2017 at 2:25 PM, Tharika Madurapperuma 
wrote:

> Hi All,
>
>In APIM 3.0, we plan to have a feature for enabling Read, Update,
> Delete permissions for an API based on roles in API Publisher. For user
> validation purposes, we need to retrieve the list of roles for the loggedin
> user. This role list is retrieved using the user's SCIM Id. But since the
> admin user by default does not have an ID as per [1] and is not regarded as
> a SCIM user, we wont be able to retrieve the list of roles for the admin.
>
>There are two possible options for making this work.
>
>*Option 1: *Either from APIM 3.0 side we should make a call to the
> SCIM endpoint and update the admin user to have a SCIM ID as in [1],
> preferably during startup or
>   * Option 2: *We can make the admin user have an Id by default from SCIM
> Implementation in IS.
>
>If we go with Option 1, it amounts to an additional call to the SCIM
> endpoint to update the user and a question arises as to where we should be
> updating it. The SCIM Id for the admin user is needed only in this scenario
> for retrieving roles currently, hence updating the admin user during
> startup is questionable.
>
>IMO Option 2 is preferrable because it will not result in an additional
> update as in Option 1 above.
>
>WDYT?
>
>Will there be any plans to include this capability in IS 5.4.0?
>
This capability will not include in IS 5.4.0 release, if this is urgent, we
can prioritize

Thanks
Isura.

>
>[1] [Dev] [IS] Admin/Tenant Admin Users cannot be filtered to get the
> SCIM ID
>
> Thanks,
> Tharika.
>
> --
> *Tharika Madurapperuma*
> Software Engineer | WSO2, Inc.
>
> Email : thar...@wso2.com
> Mobile : +94777875624 <+94%2077%20787%205624>
> Web : http://wso2.com
>
> 
>



-- 

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

[Isura Karunaratne]

Hi,

On Wed, May 31, 2017 at 1:23 PM, Asela Pathberiya  wrote:

>
>
> On Wed, May 31, 2017 at 1:08 PM, Farasath Ahamed 
> wrote:
>
>>
>> On Wed, May 31, 2017 at 12:28 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi Dinali,
>>>
>>> Consider the following calculation.
>>>
>>> expiry time = issuedTimeInMillis + validityPeriodMillis -
>>> (System.currentTimeMillis() - timestampSkew)
>>>
>>> So actually token is valid for (validityPeriodMillis + timestampSkew)
>>> seconds. This additional time is added to avoid the error occurred due to
>>> the time synchronization issues between servers.
>>>
>>> If your servers are perfectly synced then you can use timestampSkew
>>> value as 0.
>>>
>>
>> If we do not have any reasoning behind this 300s value the shouldn't our
>> default value be 0 as Dinali has suggested?
>>
>
> Yes.  Best practice is to syn server's time properly.  +1 keeping  0 as
> the default value..
>
We will fix this in IS 5.4.0. Created a Jira to track [1]

Thanks
Isura.

[1] https://wso2.org/jira/browse/IDENTITY-6033

>
>
>>
>>
>>> Thanks,
>>> Thanuja
>>>
>>>
>>> On Wed, May 31, 2017 at 12:01 PM, Dinali Dabarera 
>>> wrote:
>>>
 Hi All,

 In our identity.xml the default timeStampScrew value is used as 300
 seconds. Shouldn't this be 0 seconds?

 Because when we are getting a token from password grant type again and
 again *without a time delay*, the expiry time of the token
 increases than its accepted value because of this equation we are using.

 expiry time = issuedTimeInMillis + validityPeriodMillis - (System.
 currentTimeMillis() - timestampSkew);

 Since timestampSkew = 300 seconds, validityPeriodMillis = 3600 seconds,
 therefore, expiry time = 3644 seconds which can not be happened.

 Therefore, it is better to have the default timeStampScrew value as 0
 seconds in order to get correct results.


 Thanks!

 --
 *Dinali Rosemin Dabarera*
 Software Engineer
 WSO2 Lanka (pvt) Ltd.
 Web: http://wso2.com/
 Email : gdrdabar...@gmail.com
 LinkedIn 
 Mobile: +94770198933 <+94%2077%20019%208933>




 














>>>
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Associate Technical Lead
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891
>>>
>>> ___
>>> 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 & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810 <+94%2077%20225%204810>
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Force Delete Identity Providers

[Isura Karunaratne]

On Thu, May 25, 2017 at 1:02 PM, Thanuja Jayasinghe 
wrote:

>
>
> On Fri, May 19, 2017 at 10:05 AM, Malithi Edirisinghe 
> wrote:
>
>>
>>
>> On Fri, May 19, 2017 at 9:19 AM, Ishara Karunarathna 
>> wrote:
>>
>>>
>>>
>>> On Fri, May 19, 2017 at 1:15 AM, Malithi Edirisinghe 
>>> wrote:
>>>
 Hi All,

 So in order to support force delete an identity provider, we have to
 first identify the places the respective identity provider can be referred
 and then we need to decide on the options we have, on removing those
 references.
 Basically, an identity provider is referred by a service provider in
 authentications steps and/or as a outbound provisioning connector. So I
 think we can have below options.

 1. In authentication steps
 - If the respective IdP is the only step being configured
 Here we can simply remove it and set the local and outbound config of
 default SP (Even when there's no local and outbound config the default SP
 config is being picked).
 - If IdP is configured as a step among multiple authentication steps
 Here unless it's being specifically configured to be used to pick
 subject identifier or subject attributes, we can simply remove it. If it's
 configured to pick the subject identifier or attributes, we can follow a
 pattern like configuring the immediate step to pick the identifier or
 attributes. So, if it's the last, start from first step.
 - If IdP is configured as multi option in any step
 Here we can simply remove it, so the step will have only rest of the
 options

 2. In outbound provisioning
 Here we can simply remove the reference of the IdP as a outbound
 provisioning connector.
 Yet, whatever we do, it should be upon confirmation of the user to
 force delete and the way the IdP is removed from SP references should be
 properly recorded in audit logs. In addition, I think it's better if we can
 notify the user on which SPs are affected and some info with that regard.
 Also, when asking for the confirmation from user to force delete, it
 would be better if can indicate how many SPs are getting affected.
 So at the moment we restrict the IdP deletion by checking for
 references with [1]. So I think we can simply introduce a similar method to
 the service API, that checks the SPs being referenced, to be invoked when
 requesting confirmation. Then upon confirmation deletion can be performed
 as above.

>>> I think its hard to provide a generic, Customers may have different
>>> usecases and customization around this. Automatically deleting them can be
>>> a risk.
>>> Even if we delete them automatically customers may have to go back and
>>> modify SP configurations accordingly.
>>>
>>>
>> It's the customers decision to force delete or not. We can highlight the
>> consequences. As I said above, it's important to record the SPs effected
>> and how they are effected. IMO, we should generate some report and notify.
>> So that, if someone decide to force delete, before proceeding, he knows
>> that it's getting effected to the SPs configured and the consequences and
>> after performing he knows who are effected and what he may have to
>> reconfigure.
>>
>
> Also, we can suggest customer to fist disable the IDP and check whether
> everything works fine. Then he can proceed with the force delete.
>

Currently, It is not possible to disable IDPs which are referred by SPs.
IMO, it is better to support forcefully disable as well.

This will minimize the risk associated with forceful delete.

>
>>
>>>
>>>
>>>

 [1]  https://github.com/wso2/carbon-identity-framework/blob/mast
 er/components/idp-mgt/org.wso2.carbon.idp.mgt/src/main/java/
 org/wso2/carbon/idp/mgt/dao/IdPManagementDAO.java#L1759

 Thanks,
 Malithi.

 On Thu, May 18, 2017 at 1:22 PM, Prabath Siriwardena 
 wrote:

>
>
> On Thu, May 18, 2017 at 12:09 AM, Ishara Karunarathna <
> isha...@wso2.com> wrote:
>
>> Hi,
>>
>> On Wed, May 17, 2017 at 10:14 PM, Prabath Siriwardena <
>> prab...@wso2.com> wrote:
>>
>>> At the moment we can't delete an identity provider, if its
>>> associated with one or more service providers.
>>>
>>> Also - for the user there is no way to find out the associated
>>> service providers for a given identity provider - without going through
>>> each and every service provider config.
>>>
>>> This is fine (or just okay) if we have 2 or 3 service providers in
>>> the system - but its not the case today.
>>>
>>> Can we provide a feature to force delete an identity provider? If
>>> not at the UI - at least at the API level..
>>>
>> There are some issues if we delete IDP forcefully.
>> Ex : As Farasath raised off line how we changed 

Re: [Architecture] [C5] Self signup feature in APIM store

[Isura Karunaratne]

Hi Bhathiya,


On Wed, Apr 19, 2017 at 1:15 AM, Bhathiya Jayasekara <bhath...@wso2.com>
wrote:

> Hi Darshana,
>
> Please find my opinions inline.
>
> On Wed, Apr 19, 2017 at 11:19 AM, Darshana Gunawardana <darsh...@wso2.com>
> wrote:
>
>> Hi all,
>>
>> Please find few questions on the requirement and deployment below.
>>
>>1. Does APIM really need the self signup UI in the store?
>>
>> APIM Store is usually exposed to the external app developers too.
> Therefore self signup feature is required.
>
>>
>>1. Even we assume it need the self signup capability, as per the
>>above approach, store application (UI) consume self signup APIs in the
>>server. Are we expected to have this APIs on the KM server or the AM-Core
>>server?
>>
>> We will be having the service in APIM-core, and it will call IDP
> internally.
>
>>
>>1. If these APIs expected to have in the KM server, since we using a
>>proprietary APIs to register users, it would be an issue when APIM try to
>>integrate with an external KM, isn't it? What is the solution we in this
>>case?
>>
>> In APIM core, we provide an extension point (i.e. IDP interface) so that
> IDP calls can be implemented according to the IDP that is used. The default
> one will be calling IS.
>
> However, if we use SCIM to write the default implementation, external KMs
> who support SCIM won't be needing to write that again. There we have an
> advantage with SCIM over the proprietary API.
>

In that case you can use SCIM for user registraion and use the new REST
APIs to confirm and resend the confirmation links.

Thanks
Isura.


> Thanks,
> Bhathiya
>
> Thanks,
>>
>> On Tue, Apr 18, 2017 at 6:37 PM, Bhathiya Jayasekara <bhath...@wso2.com>
>> wrote:
>>
>>> Thanks for the information, Isura. I'll use that.
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Tue, Apr 18, 2017 at 6:33 PM, Isura Karunaratne <is...@wso2.com>
>>> wrote:
>>>
>>>> Hi Bhathiya,
>>>>
>>>> You better to go with new REST API service [1], because it supports
>>>> two-step verification. That means when user self-registered, an email will
>>>> be sent to users email address, then user cannot login to the system until
>>>> confirming the email. Also, we can resend the confirmation code
>>>> functionality also available in new REST APIs
>>>>
>>>> Thanks
>>>> Isura.
>>>>
>>>> [1] https://docs.wso2.com/display/IS530/apidocs/self-registr
>>>> ation/#!/operations#SelfRegister#mePost
>>>>
>>>>
>>>>
>>>> On Tue, Apr 18, 2017 at 2:09 AM, Bhathiya Jayasekara <bhath...@wso2.com
>>>> > wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> In C4, APIM was using identity server's "UserRegistrationAdminService"
>>>>> SOAP service to register new users. But APIM itself managed workflows
>>>>> related to self-signup.
>>>>>
>>>>> But since IS has workflow features now, in C5 we are planning to reuse
>>>>> complete user signup feature of IS in APIM too.
>>>>>
>>>>> Now we need a REST service to add/register users in IS. I was planning
>>>>> to use SCIM APIs for this purpose. But I got to know there is a
>>>>> separate REST service[1] to register users.
>>>>>
>>>>> *@IS team:* What is your recommendation here? What are the advantages
>>>>> we get from one over the other?
>>>>>
>>>>> Appreciate your responses.
>>>>>
>>>>> [1] https://docs.wso2.com/display/IS530/apidocs/self-registr
>>>>> ation/#!/operations#SelfRegister#mePost
>>>>>
>>>>> Thanks,
>>>>> --
>>>>> *Bhathiya Jayasekara*
>>>>> *Associate Technical Lead,*
>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>
>>>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>> <https://twitter.com/bhathiyax>*
>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>
>>>>
>>&g

Re: [Architecture] [C5] Self signup feature in APIM store

[Isura Karunaratne]

Hi Bhathiya,

You better to go with new REST API service [1], because it supports
two-step verification. That means when user self-registered, an email will
be sent to users email address, then user cannot login to the system until
confirming the email. Also, we can resend the confirmation code
functionality also available in new REST APIs

Thanks
Isura.

[1] https://docs.wso2.com/display/IS530/apidocs/self-
registration/#!/operations#SelfRegister#mePost



On Tue, Apr 18, 2017 at 2:09 AM, Bhathiya Jayasekara 
wrote:

> Hi all,
>
> In C4, APIM was using identity server's "UserRegistrationAdminService"
> SOAP service to register new users. But APIM itself managed workflows
> related to self-signup.
>
> But since IS has workflow features now, in C5 we are planning to reuse
> complete user signup feature of IS in APIM too.
>
> Now we need a REST service to add/register users in IS. I was planning to
> use SCIM APIs for this purpose. But I got to know there is a separate REST
> service[1] to register users.
>
> *@IS team:* What is your recommendation here? What are the advantages we
> get from one over the other?
>
> Appreciate your responses.
>
> [1] https://docs.wso2.com/display/IS530/apidocs/self-
> registration/#!/operations#SelfRegister#mePost
>
> Thanks,
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax *
> *Blog: http://movingaheadblog.blogspot.com
> *
>



-- 

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Password Policy Validation

[Isura Karunaratne]

Hi Gayan,



On Thu, Mar 23, 2017 at 11:56 PM, Gayan Gunawardana  wrote:

> Hi All,
>
> We are in the process of Implementing password policy validation feature
> for IS 6.0.0.
> Up to IS 5.3.0 there are set of default password policies.
>
>
>- Password Length Policy (check max length, min length)
>- Password Name Policy (check equality of username and password)
>- Password Pattern Policy (check password against given regex pattern)
>
> In the password policy validation process, it goes through each and every
> policies to check validity. If one of them fail password policy validation
> will be failed. Further if we add custom policy it will be evaluated in
> addition to default policies.
>
> IS 6.0.0 we have done bit of change.
>
> By default there are two ways to define password policies
>
>1. From regex pattern.
>2. By using set of properties like min length, max length, lower case,
>upper case.
>
>
> *Identity Admin can define password policies by using regex pattern or set
> of properties but not both. *
> Also there is a flexibility to define custom password policies. You will
> have two configurations under password policies, one is to enable password
> policy validation and another one is to enable default password policy
> validation.
>
What do you mean by custom password policies? is it same as regex pattern
validation?

Why is it required to have two configurations? We can support a default
validation and if anyone requires changing that, he/she can define a custom
policy. I don't mind any requirement to have both default password
validation and custom validation at once since we can define any validation
through a custom policy.

Thanks
Isura.


>
> In case if you want to have both, default password policies and custom
> password policies then you can keep both configurations are enabled. If you
> want to enable only custom policy then you can disable default policies.
>
> Appreciate your suggestions regarding this.
>

> Thanks,
> Gayan
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0][admin-portal] User Onboarding - Ask Password with email verification

[Isura Karunaratne]

Hi,



On Tue, Mar 21, 2017 at 3:55 PM, Denuwanthi De Silva 
wrote:

> Hi,
>
> Just to clarify,
>
> Let's say admin types an email address.
> For some reason he misses a character or two. And still let's say that
> email is a valid email of some one.
> Then when we add the user, an email will be sent to that mail adress. Even
> though that is not the intended user.
> If that unknown user clicks the link he can reset the password in and
> login to the user portal rit?
>
> This can be a rare situuation.
> Is this a scenario we should be concerned of? or is it already handled in
> some layer?
>

It is a resposibility of administrator to enter the correct email address.
BTW, we can reduce the human errors by having a new text box to confirm
email addresss.

Thanks
Isura

>
>
> Thanks
>
> On Tue, Mar 21, 2017 at 12:33 PM, Dinali Dabarera  wrote:
>
>> Hi,
>>
>> For the above-mentioned scenario,
>>
>>- We are going to send the link of the default password reset page to
>>the user, with that we will send a random generated code to identify the
>>user, and it will expire after a given time period.
>>- We are not going to lock the user since we use a random password
>>when storing the user in DB and it will be over written by the user
>>password update.
>>- As Sagara mentioned, we will add meaning full sentences in the UI
>>so that user experience will increase.
>>
>> Thanks.
>>
>> On Tue, Mar 21, 2017 at 10:07 AM, Godwin Shrimal  wrote:
>>
>>> Correction
>>>
>>> 1. As Isura mentioned we don't need to lock the account since we are
>>> creating the user with random password no one knows it.
>>>
>>> On Tue, Mar 21, 2017 at 10:06 AM, Godwin Shrimal 
>>> wrote:
>>>
 Hi Dinali,

 Please see my feedback below.

 1. As Isura mentioned we don't to lock the account since we are
 creating the user with random password on one knows it.
 2. Can't we use name User store (or what ever the term use in C5) other
 than Domain, its not user friendly and end users will not aware what is
 Domain.
 3. I guess combo box with available option is not user friendly and
 what about having option buttons which shows available options at once to
 user ?


 Thanks
 Godwin


 On Mon, Mar 20, 2017 at 5:53 PM, Dinali Dabarera 
 wrote:

> Hi All,
>
> I am going to implement User Onboarding - Ask Password with email
> verification according to the User story [1].The wire-frame given by the 
> UX
> team is [2].
>
> According to these,
>
> *In admin side,*
>
>- The admin creates a user and put his email and click on Add user.
>- Then an email is sent to the user's given email address.
>- The admin will redirect to the List user page.
>
> *In users side*,
>
>- The user will get a link to set a password.
>- The User can click on it and add a password.
>
> *There are two main concerns that am bothering about,*
>
>1. *When the user clicks the link, I think we can redirect to the
>change password page in user portal. Is this fine or Do we need to use 
> a
>custom page for that?*
>2. *I think we need to lock the account of that user Until he adds
>a password. Is this necessary?*
>
>
> [1] https://redmine.wso2.com/issues/5749
> [2]https://github.com/wso2-dev-ux/product-is/blob/master/Wir
> eframes/admin-portal/v3/3.5%20Add%20user%20with%20email%20ve
> rification.png
>
> ​Thank you!​
>
> --
> *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
>
>


 --
 *Godwin Amila Shrimal*
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: *+94772264165*
 linkedin: *http://lnkd.in/KUum6D *
 twitter: https://twitter.com/godwinamila
 

>>>
>>>
>>>
>>> --
>>> *Godwin Amila Shrimal*
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94772264165*
>>> linkedin: *http://lnkd.in/KUum6D *
>>> twitter: https://twitter.com/godwinamila
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> 

Re: [Architecture] [C5][IS 6.0.0] Email Verification for Existing User

[Isura Karunaratne]

Hi Ayesha,



On Tue, Mar 21, 2017 at 11:31 AM, Ayesha Dissanayaka <aye...@wso2.com>
wrote:

>
> On Tue, Mar 21, 2017 at 11:15 AM, Isura Karunaratne <is...@wso2.com>
> wrote:
>
>> There is a claim which stored whether  the user email verified or not (
>> http://wso2.org/claims/emailVerified). Once the user verified his/her
>> email, that calim's value shoudl be "true". If  the user changes his/her
>> email addresse, he/her has to verify the email again.
>>
> What if an admin changes a users email? I assume it's same behavior and
> user need to verify the email. Until then he/she will not be able to login
> to the account.
>

Admin changes users email and verify email are two seperate steps. It is
not requried to deny user login when admin changes users email address.
Then the user state will chnages to different state like
(UNLOCKED_UNVERIFIED).

We only need to lock the user, if admin intiates the verify email flow
again.

Thanks
Isura.

>
>
> --
> *Ayesha Dissanayaka*
> Senior Software Engineer,
> WSO2, Inc : http://wso2.com
> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com=D=1=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg>
> 20, Palm grove Avenue, Colombo 3
> E-Mail: aye...@wso2.com <ayshsa...@gmail.com>
>
> ___
> 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] [C5][IS 6.0.0] Email Verification for Existing User

[Isura Karunaratne]

Hi,

On Tue, Mar 21, 2017 at 10:51 AM, Godwin Shrimal  wrote:

> What happen when user modify email or telephone number ? user have to
> verify it back ?
>

There is a claim which stored whether  the user email verified or not (
http://wso2.org/claims/emailVerified). Once the user verified his/her
email, that calim's value shoudl be "true". If  the user changes his/her
email addresse, he/her has to verify the email again.

Thanks
Isura..

>
> Thanks
> Godwin
>
>
> On Tue, Mar 21, 2017 at 10:04 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi Gayan,
>>
>> User Story :
>>
>>1. User chooses to verify email of an existing user.
>>2. User selects if the user account must be locked until existing
>>user verifies his email.
>>
>> *Acceptance Criteria*
>>
>>1. The existing user must receive an email.
>>2. If the User Admin had chosen to lock the existing user account
>>until email verification, then until the existing user confirms his/her
>>email, he/she must not be able to login to the system using this account.
>>3. If the action is successful, then it should be notified in the UI.
>>4. If the action is unsuccessful, then it should be notified in the
>>UI.
>>5. User must be directed to the user listing page.
>>
>>
>> Still the wire frames are not finalized and Minoli is updating it.
>> Exisiting wireframes can be found from  [1] and [2]
>>
>> [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wi
>> reframes/admin-portal/v3/3.27%20Edit%20user%20profile%20-%
>> 20verified%20state.png
>> [2]https://github.com/wso2-dev-ux/product-is/blob/master/Wir
>> eframes/admin-portal/v3/3.25%20Edit%20user%20profile%20-%
>> 20send%20verification.png
>>
>> Thanks,
>>
>> Hasanthi Dissanayake
>>
>> Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>> On Tue, Mar 21, 2017 at 9:48 AM, Gayan Gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 21, 2017 at 9:09 AM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
 Hi All,

 I am going to implement the $subject according to the user story [1].

>>> Please mention the user story and wire frame location.
>>>
 According to the wire frame, when admin updates an existing user's
 details he has the option to verify the email address. There is an optional
 checkbox for the admin to decide whether the user account is locked or not
 untill the user verifies the email.  So if the User Admin had chosen to
 lock the existing user account until email verification, then until the
 existing user confirms his email he can not be able to login to the system
 by using his account.

 Highly appreciate any comments on this.

 Thanks,

 Hasanthi Dissanayake

 Software Engineer | WSO2

 E: hasan...@wso2.com
 M :0718407133| http://wso2.com 

>>>
>>>
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Godwin Amila Shrimal*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D *
> twitter: https://twitter.com/godwinamila
> 
>
> ___
> 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] [C5][IS 6.0.0][admin-portal] User Onboarding - Ask Password with email verification

[Isura Karunaratne]

Hi Dinali,

On Mon, Mar 20, 2017 at 10:05 PM Sagara Gunathunga  wrote:

>
>
> On Mon, Mar 20, 2017 at 7:22 PM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
> Hi Dinali,
>
> *There are two main concerns that am bothering about,*
>
>1. *When the user clicks the link, I think we can redirect to the
>change password page in user portal. Is this fine or Do we need to use a
>custom page for that?*
>
> IMO  redirecting to the change password page in user portal is fine here
> as this is an actual password reset. (Not a temporary pass code)
>
>
In IS6.0.0 we can create HTML based email templates, we better to support a
button in the email rather than a email link. In this way we can get rid of
printing confirmation codes in http access logs since we can pass the
confirmation code in post body.

We have to follow this approach for self signup and account recovery
features as well.


>2.  *I think we need to lock the account of that
> user Until he adds a password. Is this necessary?*
>
> +1. I think the account should be locked until the user sets a password.
>
> As those features are already implemented in IS 5.3.0 it is better if we
> can study the existing behaviors as well.
>
>
I think we don't need to lock the user in ask password flow. The password
should be a auto generated one and none knows the password at time of
creating the user.

Thanks
Isura.

>
> Thanks,
>
>
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>
> On Mon, Mar 20, 2017 at 5:53 PM, Dinali Dabarera  wrote:
>
> Hi All,
>
> I am going to implement User Onboarding - Ask Password with email
> verification according to the User story [1].The wire-frame given by the UX
> team is [2].
>
> According to these,
>
> *In admin side,*
>
>- The admin creates a user and put his email and click on Add user.
>- Then an email is sent to the user's given email address.
>- The admin will redirect to the List user page.
>
> *In users side*,
>
>- The user will get a link to set a password.
>- The User can click on it and add a password.
>
> *There are two main concerns that am bothering about,*
>
>1. *When the user clicks the link, I think we can redirect to the
>change password page in user portal. Is this fine or Do we need to use a
>custom page for that?*
>2. *I think we need to lock the account of that user Until he adds a
>password. Is this necessary?*
>
>
> [1] https://redmine.wso2.com/issues/5749
> [2]
> https://github.com/wso2-dev-ux/product-is/blob/master/Wireframes/admin-portal/v3/3.5%20Add%20user%20with%20email%20verification.png
>
>
> Please pay more attention on UX design, it is not just graphical
> arrangements you have to wear user's hat and see what is the experience
> from that side.
>
> - Instead of just "Domain" can't we use something like "Select a domain to
> add new user" ?
>
> - Helper texts are missing in UIs.
>
> - "Select Method " does not make any sense to me.
>
> - "E-mail" - > Enter the e-mail address of new user  and it's important to
> have helper text here explaining what system going to do with provided
> e-mail
>
>
>
> Thanks !
>
>
> ​Thank you!​
>
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> 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
>
-- 

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

[Isura Karunaratne]

On Mon, Mar 20, 2017 at 11:51 AM, Isura Karunaratne <is...@wso2.com> wrote:

> Hi Omindu,
>
>
>
> On Mon, Mar 13, 2017 at 5:00 PM, Omindu Rathnaweera <omi...@wso2.com>
> wrote:
>
>> Hi,
>>
>> On Sun, Mar 12, 2017 at 7:59 AM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
>>
>>> Hi All,
>>> Can the hash algorithm change over the time?
>>> If so we need to record the hash algorithm used to do hashing along with
>>> the particular password history record. We need to use the particular
>>> algorithm to do the comparison, not the system configured one.
>>>
>>
>> In addition to the hashing algo, we should store the key length and the
>> iteration count. We have given the option to configure these properties for
>> the credential stores and we should do the same for password history
>> management. Since we are storing the current password in the history table,
>> the hashing mechanism should be similar to that of the credential stores.
>>
> -
> I don't think we need to use the same hashing algorithm since we are using
> salted password. We store the passwords in password history table only if
> we enable this feature. So, the clients who don't like to duplicate their
> passwords in Identity tables can disable the password history feature and
> use the feature supported in relavant user store such Active Directory.
>
> Thanks
> Isura.
>
>>
>> Regards,
>> Omindu.
>>
>>
>>>
>>> Cheers,
>>> Ruwan
>>>
>>>
>>> On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana <ga...@wso2.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> We are in the process of implementing password history validation
>>>> feature for IS 6.0.0. Architecture of this feature was previously discussed
>>>> in [1] by Isura for IS 5.3.0. We plan to follow same architecture with
>>>> minor changes.
>>>>
>>>> Previously history validation has been done by checking only last 'n'
>>>> number of attempts. Ex. you cannot use a password which is inside last 5
>>>> attempts. This time we additionally validate time factor as well Ex. you
>>>> cannot use a password, if there is a similar password with created date
>>>> inside last 7days.
>>>>
>>>> Table structure will be changed as below since we have unique user ID
>>>> in C5.
>>>>
>>>> *Previous *
>>>>
>>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>>   USER_NAME   VARCHAR(255) NOT NULL,
>>>>   USER_DOMAIN VARCHAR(127) NOT NULL,
>>>>   TENANT_ID   INTEGER DEFAULT -1,
>>>>   SALT_VALUE  VARCHAR(255),
>>>>   HASHVARCHAR(255) NOT NULL,
>>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>>   PRIMARY KEY(ID),
>>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>>> )ENGINE INNODB;
>>>>
>>>>
>>>> *New *
>>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>>   USER_UNIQUE_ID   VARCHAR(255) NOT NULL,
>>>>   SALT_VALUE  VARCHAR(255),
>>>>   HASHVARCHAR(255) NOT NULL,
>>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>>   PRIMARY KEY(ID),
>>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>>> )ENGINE INNODB;
>>>>
>>>> Password Hashing algorithm will be a configurable property.
>>>>
>>>> [1] [Architecture] Force Password Reset and Password History validation
>>>>
>>>> Thanks,
>>>> Gayan
>>>>
>>>> --
>>>> Gayan Gunawardana
>>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>>> Email: ga...@wso2.com
>>>> Mobile: +94 (71) 8020933
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Ruwan Abeykoon*
>>> *Associate Director/Architect**,*
>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>>> *lean.enterprise.middleware.*
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Omindu Rathnaweera
>> Software Engineer, WSO2 Inc.
>> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>>
>> ___
>> 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] [C5][IS 6.0.0] Password History Validation

[Isura Karunaratne]

Hi Omindu,



On Mon, Mar 13, 2017 at 5:00 PM, Omindu Rathnaweera  wrote:

> Hi,
>
> On Sun, Mar 12, 2017 at 7:59 AM, Ruwan Abeykoon  wrote:
>
>> Hi All,
>> Can the hash algorithm change over the time?
>> If so we need to record the hash algorithm used to do hashing along with
>> the particular password history record. We need to use the particular
>> algorithm to do the comparison, not the system configured one.
>>
>
> In addition to the hashing algo, we should store the key length and the
> iteration count. We have given the option to configure these properties for
> the credential stores and we should do the same for password history
> management. Since we are storing the current password in the history table,
> the hashing mechanism should be similar to that of the credential stores.
>

I don't think we need to use hashing algorithm since we are using salted
password. We store the passwords in password history table only if we
enable this feature. So, the clients who don't like to duplicate their
passwords in Identity tables can disable the password history feature and
use the feature supported in relavant user store such Active Directory.

Thanks
Isura.

>
> Regards,
> Omindu.
>
>
>>
>> Cheers,
>> Ruwan
>>
>>
>> On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are in the process of implementing password history validation
>>> feature for IS 6.0.0. Architecture of this feature was previously discussed
>>> in [1] by Isura for IS 5.3.0. We plan to follow same architecture with
>>> minor changes.
>>>
>>> Previously history validation has been done by checking only last 'n'
>>> number of attempts. Ex. you cannot use a password which is inside last 5
>>> attempts. This time we additionally validate time factor as well Ex. you
>>> cannot use a password, if there is a similar password with created date
>>> inside last 7days.
>>>
>>> Table structure will be changed as below since we have unique user ID in
>>> C5.
>>>
>>> *Previous *
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>   USER_NAME   VARCHAR(255) NOT NULL,
>>>   USER_DOMAIN VARCHAR(127) NOT NULL,
>>>   TENANT_ID   INTEGER DEFAULT -1,
>>>   SALT_VALUE  VARCHAR(255),
>>>   HASHVARCHAR(255) NOT NULL,
>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>   PRIMARY KEY(ID),
>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>> )ENGINE INNODB;
>>>
>>>
>>> *New *
>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>   USER_UNIQUE_ID   VARCHAR(255) NOT NULL,
>>>   SALT_VALUE  VARCHAR(255),
>>>   HASHVARCHAR(255) NOT NULL,
>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>   PRIMARY KEY(ID),
>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>> )ENGINE INNODB;
>>>
>>> Password Hashing algorithm will be a configurable property.
>>>
>>> [1] [Architecture] Force Password Reset and Password History validation
>>>
>>> Thanks,
>>> Gayan
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com  *
>> *lean.enterprise.middleware.*
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Omindu Rathnaweera
> Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>
> ___
> 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] [C5][IS 6.0.0] Password History Validation

[Isura Karunaratne]

Hi Joahnn,



On Mon, Mar 13, 2017 at 9:14 AM, Johann Nallathamby <joh...@wso2.com> wrote:

>
>
> On Mon, Mar 13, 2017 at 9:03 AM, Isura Karunaratne <is...@wso2.com> wrote:
>
>> Hi Gayan,
>>
>>
>> On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana <ga...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> We are in the process of implementing password history validation
>>> feature for IS 6.0.0. Architecture of this feature was previously discussed
>>> in [1] by Isura for IS 5.3.0. We plan to follow same architecture with
>>> minor changes.
>>>
>>> Previously history validation has been done by checking only last 'n'
>>> number of attempts. Ex. you cannot use a password which is inside last 5
>>> attempts. This time we additionally validate time factor as well Ex. you
>>> cannot use a password, if there is a similar password with created date
>>> inside last 7days.
>>>
>>> Table structure will be changed as below since we have unique user ID in
>>> C5.
>>>
>>> *Previous *
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>   USER_NAME   VARCHAR(255) NOT NULL,
>>>   USER_DOMAIN VARCHAR(127) NOT NULL,
>>>   TENANT_ID   INTEGER DEFAULT -1,
>>>   SALT_VALUE  VARCHAR(255),
>>>   HASHVARCHAR(255) NOT NULL,
>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>   PRIMARY KEY(ID),
>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>> )ENGINE INNODB;
>>>
>>>
>>> *New *
>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>   USER_UNIQUE_ID   VARCHAR(255) NOT NULL,
>>>   SALT_VALUE  VARCHAR(255),
>>>   HASHVARCHAR(255) NOT NULL,
>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>   PRIMARY KEY(ID),
>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>>
>>
>> This should be  UNIQUE (USER_UNIQUE_ID,SALT_VALUE,HASH)
>>
>
> USER_UNIQUE_ID by itself is globally unique. Then is there a point to have
> this unique constraint?
>
No. Multiple recodrs will be there for same uniqueId.

Thanks
Isura.

>
>
>>
>>
>> Thanks
>> Isura.
>>
>>> )ENGINE INNODB;
>>>
>>> Password Hashing algorithm will be a configurable property.
>>>
>>> [1] [Architecture] Force Password Reset and Password History validation
>>>
>>> Thanks,
>>> Gayan
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

[Isura Karunaratne]

Hi Gayan,


On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana  wrote:

> Hi All,
>
> We are in the process of implementing password history validation feature
> for IS 6.0.0. Architecture of this feature was previously discussed in [1]
> by Isura for IS 5.3.0. We plan to follow same architecture with minor
> changes.
>
> Previously history validation has been done by checking only last 'n'
> number of attempts. Ex. you cannot use a password which is inside last 5
> attempts. This time we additionally validate time factor as well Ex. you
> cannot use a password, if there is a similar password with created date
> inside last 7days.
>
> Table structure will be changed as below since we have unique user ID in
> C5.
>
> *Previous *
>
> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>   ID INTEGER NOT NULL AUTO_INCREMENT,
>   USER_NAME   VARCHAR(255) NOT NULL,
>   USER_DOMAIN VARCHAR(127) NOT NULL,
>   TENANT_ID   INTEGER DEFAULT -1,
>   SALT_VALUE  VARCHAR(255),
>   HASHVARCHAR(255) NOT NULL,
>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>   PRIMARY KEY(ID),
>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
> )ENGINE INNODB;
>
>
> *New *
> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>   ID INTEGER NOT NULL AUTO_INCREMENT,
>   USER_UNIQUE_ID   VARCHAR(255) NOT NULL,
>   SALT_VALUE  VARCHAR(255),
>   HASHVARCHAR(255) NOT NULL,
>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>   PRIMARY KEY(ID),
>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>

This should be  UNIQUE (USER_UNIQUE_ID,SALT_VALUE,HASH)


Thanks
Isura.

> )ENGINE INNODB;
>
> Password Hashing algorithm will be a configurable property.
>
> [1] [Architecture] Force Password Reset and Password History validation
>
> Thanks,
> Gayan
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS] Authentication Failures handle in two different way in User Core API

[Isura Karunaratne]

Hi,



On Sun, Mar 12, 2017 at 8:11 PM, Harsha Thirimanna  wrote:

> Hi,
>
> There is an implementation for authentication failure in two different way
> by  authenticate API in IdentityStore.
> If the username is invalid or empty, then API throws an
> *AuthenticationFailure* exception and if the password is wrong, then the
> API returns  *FailedA**uthenticationContext*.
>
> Don't we need to make consistent for both cases ? Any special reason to do
> this ?
>
As omindu mentioned, failedAuthenicationContext was implemented to return
authentication failed users for post handlers [1]. In these two cases,
there is no valid users in server. +1 to return FailedAuthenticationContext
with empty user list for these scenarios and  remove
AuthenticationFailure exeption
from method.

Thanks
Isura.

[1] [IAM] [IS6.0.0] How to handle post Authentication in IS 6.0.0


>
> public AuthenticationContext authenticate(Claim claim, Callback[] credentials,
>
> String domainName) throws AuthenticationFailure, 
> IdentityStoreException {
>
>
>
> *Harsha Thirimanna*
> *Associate Tech Lead | WSO2*
>
> Email: hars...@wso2.com
> Mob: +94715186770 <+94%2071%20518%206770>
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/ha
> rsha-thirimanna/10/ab8/122
> 
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] How to identifying a self sign-up request

[Isura Karunaratne]

Hi Maduranga,

On Fri, Mar 3, 2017 at 8:11 AM Maduranga Siriwardena 
wrote:

> Hi Omindu,
>
> So the implementation of POST in /me endpoint will call addUser with
> special role and /User will call addUser without special role, right? So
> this address my concern.
>

Yes, but it is a special Group, not a role.

Thanks
Isura.

>
> Thanks,
>
> On Thu, Mar 2, 2017 at 6:34 PM, Omindu Rathnaweera 
> wrote:
>
> Hi All,
>
> As per the offline discussion we had on the subject, we will be taking the
> following approach.
>
> Self sign-up can be achieved by SCIM /Me endpoint and the self
> sign-up REST endpoint. In addition to the self sign-up, the REST endpoint
> will have support for confirmation code resend, and confirmation code
> verification.
>
> As Johann pointed out, there should be a way to identify a self sign-up
> users and searching through user claims or meta attributes will not be the
> ideal solution considering the performance overhead. Therefore, we will be
> introducing a reserved group for the self sign-up user and the Identity
> Store API will have overloaded methods to add users with groups. And the
> REST endpoints will be calling these methods for self sign-up internally.
>
>
> *User addUser(UserBean userBean, List groupIdList) throws
> IdentityStoreException*
>
> *User addUser(UserBean userBean, String domainName, List
> groupIdList) throws IdentityStoreException*
>
> Also by introducing the overloaded method, we can overcome the problem of
> identifying the self sign-up user. How we achieve this is by making the
> self sign-up handler subscribe to the over loaded add user method.
> Therefore, to start a self sign-up flow, one should call the overloaded
> addUser method with the self sign-up group's unique ID. The handler will
> check for the self sign-up group id to identify the whether the addUser
> operation is related to self sign-up.
>
> @Sewmini: /User endpoint will not be supporting self sign-up.
>
> @Maduranga:
>
> The primary difference between the self sign-up endpoint and the normal
> user provisioning endpoint is one needs authentication and one does not
> need authentication. So can't we use the separation to distinguish the 2
> operation. Do we have a way to identify whether this request is
> authenticated or not during the execution of the handler?
>
>
> If we only consider the REST endpoints, it is a valid point. But the REST
> endpoints will not be the only place which will trigger the self
> sign-up flow. So I'm not quite confident whether we can rely on the fact
> that there won't be an authenticated user for the self sign-up flow.
>
> I think if we use some claim/role/attribute to distinguish this, there
> might be problems with the situations where client will not send
> the claim/role/attribute when it is required and vice versa.
>
>
> With the new approach, the REST service consumers won't need to specify a
> group for self sign-up.
>
> Thanks,
> Omindu.
>
> On Thu, Mar 2, 2017 at 6:57 AM, Omindu Rathnaweera 
> wrote:
>
> Hi Johann,
>
> Why do we need to keep on supporting this if /Me has the same
> functionality? I think we must not have this if we can do the same things
> with /Me, with/without extensions to /Me (meaning additional params,
> headers, etc. which SCIM2 doesn't stop us from doing).
>
>
> With /Me endpoint, we can achieve user registration, but the user
> confirmation, resend confirmation code functionalities have to be given by
> the self sign up REST API unless we introduce SCIM resource extensions.
>
>
> The primary reason we have a separate /Me endpoint for self-signup is to
> avoid authentication. @Gayan: correct me if I am wrong. Otherwise at a
> protocol level there aren't much differences between /Me "self-signup" API
> and /Users "create" API.
>
> The reason why we needed to support self-signup flow using our addUser API
> in IS 5.3.0 was because, we needed an API which is not open but protected
> by some form of authentication/authorization that client applications can
> invoke on behalf of the user.
>
> In that case why don't we give an option to secure the self-signup API
> itself, which is very easy now if we have Ruwan's interceptor working, and
> not allow self-signup flow using /Users endpoint?
>
>
> Correct me if I've understood this wrong. With this approach we are
> limiting the origin of SSU request only to the REST API/OSGi service and
> eliminate the need to identify whether the request is for SSU or not ?
>
> If that's the case we can even get rid of the SSU handler and do
> everything in the self sign-up manager OSGi service. But I was under the
> assumption that, we should not limit the capability to initiate the SSU
> flow only to the REST API and the OSGi service. With the handler, whenever
> we call the addUser method, we can trigger the SSU flow (given that we can
> identify it's a SSU request).
>
>
> Now the second question is how do we identify the self-signup users once

Re: [Architecture] How to identifying a self sign-up request

[Isura Karunaratne]

In IS 5.3.0, we used a self-signup role to distinguish self-signup requests
from other provisioning requests, It is not possible to add users with
roles/groups in new Identity store architecture. So, I am +1 to user a
special claim.

Thanks
Isura.


*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/




On Wed, Mar 1, 2017 at 3:53 PM, Omindu Rathnaweera  wrote:

> Hi All,
>
> For the user self sign-up feature in IS 6.0.0, we have a requirement to
> distinguish a self sign-up request from a normal user provisioning
> operation.
>
> In IS 6.0.0 currently, a user can self sign-up using one of the following
> 2 mechanisms.
>
> 1. Using self sign-up REST API.
> 2. Using SCIM provisioning endpoints (/Me, /User)
>
> The self sign-up operation will be achieved by the means of an event
> handler which will be triggered during PRE and POST addUser() operations.
> Therefore, for any user add operation call, the self sign-up event handler
> will be triggered and from the handler, we have to identify whether it is a
> self -sign-up request or not.
>
> One possible way to achieve this is by sending a special claim along with
> the UserBean and from the self sign-up event handler we check for the
> mentioned claim before starting the self sign-up flow.
>
> Appreciate your thoughts on this.
>
> Thanks,
> Omindu
>
> --
> Omindu Rathnaweera
> Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IAM] Implement new addLifecycle method with life-cycle Id as an input parameter

[Isura Karunaratne]

Hi,

In the current implementation of Lifecycle management module [1], it will
be generated a unique UUID as the lifecycle id. Shall we implement another
addLifecycle method which we can pass lifecycle Id as an input parameter?
In this way we can use, unique userId as the user lifecycle Id. WDYT ?

public static LifecycleState addLifecycle(String lcName, String user) throws
LifecycleException {

Thanks
Isura.



[1] https://github.com/wso2/carbon-lcm


*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Extend SCIM 2.0 Metadata to include User Lifecycle State

[Isura Karunaratne]

Hi Ruwan,

Lifecycle data are stored in a separate table (LC_DATA) which can be in a
different datastore. Here we want to duplicate the data in IDM_USER table
to increase the read performance. Join operation will not work since
Identity and Lifecycle data can be stored in two databases.


CREATE TABLE IF NOT EXISTS LC_DATA(
LC_STATE_ID VARCHAR(36),
LC_NAME VARCHAR(255),
LC_STATUS VARCHAR(255),
UNIQUE (LC_STATE_ID),
PRIMARY KEY (LC_STATE_ID)
);


Thanks
Isura.



On Mon, Feb 13, 2017 at 1:28 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:

> HI Johann,
> I would think adding lifecycle state in "IDM_USER" is violation of
> database fundamentals.
>
>
> 1. IDM_USER will hold fairly static data and read most, updated less.
> 2. Lifecycle data will be modified mostly.
> 3. There is no noticeable performance gain/loss of Join vs having it in
> single table. [1], for properly written joins.
>
> I think it is best to keep all the lifecycle related data in independent
> table structure, since lifecycle management is separate feature.
>
> Have we encountered any specific performance issue in having then in
> different tables previously? if not, can we put all the lifecycle related
> info in its own tables, while keeping IDM_USER clean.
>
>
> [1] http://stackoverflow.com/questions/477226/sql-joins-vs-s
> ingle-table-performance-difference
>
>
> On Mon, Feb 13, 2017 at 1:03 PM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>>
>>
>> On Mon, Feb 13, 2017 at 11:22 AM, Thanuja Jayasinghe <than...@wso2.com>
>> wrote:
>>
>>> Hi Johann / Isura,
>>>
>>> On Tue, Feb 7, 2017 at 10:00 PM, Johann Nallathamby <joh...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 8, 2017 at 9:25 AM, Isura Karunaratne <is...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Johann,
>>>>>
>>>>>
>>>>> On Wed, Feb 8, 2017 at 9:19 AM, Johann Nallathamby <joh...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> For IS 6.0.0 M3 we decided to implement and manage user lifecycle
>>>>>> states. For IS 6.0.0 M2 we are implementing SCIM 2.0. I propose that we
>>>>>> extend SCIM 2.0 metadata and include the user lifecycle state as a user's
>>>>>> metadata.
>>>>>>
>>>>>> Also regarding where we need to store this metadata, I think it needs
>>>>>> to be stored in a column in the UM_USER table. This means we don't have 
>>>>>> to
>>>>>> go to the identity store to fetch user's state for most of the operations
>>>>>> we will be performing on the user.
>>>>>>
>>>>>> Should we store state and lifecycleId in UM_USER table or IDM_USER
>>>>> table ?
>>>>>
>>>>
>>>> Sorry it should be IDM_USER. This will be irrespective of underlying
>>>> identity store type.
>>>>
>>>>
>>> IDM_USER table comes with the default UniqueUserIdResolver
>>> implementation. When we connect to an existing user store( basically when
>>> we have deferent UniqueUserIdResolver implementation), we can't garauntee
>>> that this table will be included in the schema.
>>>
>>> Since life cycle status is mandotery, it should not depend on the
>>> IDM_USER table to store values?
>>>
>>
>> Keeping lifecycle state in IDM_USER means now we treat lifecycle state as
>> a first class user metadata in our identity-mgt implementation. And also in
>> future we will treat all the SCIM 2.0 metadata also as first class in
>> identity-mgt implementation. This is purely for performance reasons. So we
>> should not be thinking as if lifecycle depends on identity-mgt. Even
>> without lifecycle-mgt that table must be populated now with initial
>> lifecycle state "CREATED". However we may not be able to transition between
>> states without lifecycle-mgt feature.
>>
>>>
>>>
>>>>
>>>>> Thanks
>>>>> Isura
>>>>>
>>>>>
>>>>>
>>>>>> On a different note I think we also need to merge the SCIM2.0
>>>>>> metadata table with UM_USER table so that all SCIM 2.0 metadata is
>>>>>> supported by our identity-mgt implementation. This will greatly improve
>>>>>> performance and avoid multiple lookups in database. Similarly we must use
>>>&g

Re: [Architecture] C5 User Core Delete User Operation

[Isura Karunaratne]

Hi Gayan,




On Wed, Feb 8, 2017 at 11:13 PM, Gayan Gunawardana  wrote:

> Hi All,
>
> How are we going to support user delete operation in user core ?
> Currently IdentityStore --> deleteUser operation delete user from user
> store. Is there any future plan to set delete flag apart from completely
> deleting user from user store.
>
> Appreciate your feedback since this is directly affected to SCIM
> implementation according to [1].
>

So, these users should be inactive.  Is this different from Account
Disabled feature ?

Thanks
Isura.

>
>
> [1]https://tools.ietf.org/html/rfc7644#section-3.6
>
> Thanks,
> Gayan
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> 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

[Architecture] [IAM] [IS6.0.0] How to handle Special claims ?

[Isura Karunaratne]

Hi all,

What is the best way to handle special claims such as last login
time and last password update time? These claims should
only be modified by the system.

Ideally, we should not be able to update these claims using an APIs such as
SCIM.

Thanks

*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IAM] [IS6.0.0] How to handle post Authentication in IS 6.0.0

[Isura Karunaratne]

Hi all,


According to the C5 Identity Mangement implementation [1], it throws
AuthenticationFailure
exception for invalid credentials and due to that, POST_AUTHENTICATION
event will *not* be triggered.  It is required to trigger
POST_AUTHENTICATION event for authentication failure scenarios as well. For
example, it is required to increment user failed login count in account
lock feature.

I think AuthenticationContext[2] class should have the authentication
status and it should be returned instead of AuthenticationFailure exception
in authentication failed scenarios. WDYT ?



[1]
https://github.com/wso2/carbon-identity-mgt/blob/master/components/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/carbon/identity/mgt/impl/IdentityStoreImpl.java#L1381
[2]
https://github.com/wso2/carbon-identity-mgt/blob/master/components/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/carbon/identity/mgt/AuthenticationContext.java#L22-22


Thanks


*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Extend SCIM 2.0 Metadata to include User Lifecycle State

[Isura Karunaratne]

Hi Johann,


On Wed, Feb 8, 2017 at 9:19 AM, Johann Nallathamby  wrote:

> For IS 6.0.0 M3 we decided to implement and manage user lifecycle states.
> For IS 6.0.0 M2 we are implementing SCIM 2.0. I propose that we extend SCIM
> 2.0 metadata and include the user lifecycle state as a user's metadata.
>
> Also regarding where we need to store this metadata, I think it needs to
> be stored in a column in the UM_USER table. This means we don't have to go
> to the identity store to fetch user's state for most of the operations we
> will be performing on the user.
>
> Should we store state and lifecycleId in UM_USER table or IDM_USER table ?

Thanks
Isura



> On a different note I think we also need to merge the SCIM2.0 metadata
> table with UM_USER table so that all SCIM 2.0 metadata is supported by our
> identity-mgt implementation. This will greatly improve performance and
> avoid multiple lookups in database. Similarly we must use UM_GROUP to store
> group metadata of SCIM 2.0.
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Isura Karunaratne]

Hi Dinali,

On Thu, Feb 2, 2017 at 7:55 PM Dinali Dabarera <din...@wso2.com> wrote:

> Hi all,
>
> In Username Recovery, I need to find a User which is available for
> multiple claims.
> So what I do now is,
>
> *Without considering the domains I go through whole users.   *
> *   |*
> *   |_ Check for users (100) per claim. ( Default I have 3 claims)  -> 
> *getUserList(String
> claimUri, String value)
> *  |*
> *  |_ Then match the common users for all claims*
> *  |*
> *  |_ If one user found, send the username to  the
> user,*
> *  If multiple found, Notify user.*
>
> I think this procedure has too much work to do.
>
> But I think it is better to have a method called  
> *getUserList(ArrayList)
> *with domain or across all domain from the userstore directly than
> comparing as above.
>
> Please leave me comments on this.
>

+1 for supporting new method in Identity Store level.

Thanks
Isura.

>
> Thanks.
>
>
> On Fri, Jan 27, 2017 at 3:03 PM, Dinali Dabarera <din...@wso2.com> wrote:
>
> Hi all,
>
> Thanks for the comments!
>
> We will implement those in our future releases.
>
> On Tue, Jan 24, 2017 at 11:36 AM, Shani Ranasinghe <sh...@wso2.com> wrote:
>
>
>
> On Sat, Jan 21, 2017 at 8:20 PM, Imesh Chandrasiri <ime...@wso2.com>
> 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 <pubu...@wso2.com>
> 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 <la...@wso2.com>
> wrote:
>
> Hi All,
>
> On Sat, Jan 21, 2017 at 1:35 PM, Isura Karunaratne <is...@wso2.com> wrote:
>
> Hi Dinali,
>
> On Sat, Jan 21, 2017 at 12:33 PM, Dinali Dabarera <din...@wso2.com> 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 <https://lk.linkedin.com/in/dinalidabarera>
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> <https://lk

Re: [Architecture] C5 - Groups vs Roles

[Isura Karunaratne]

Hi Manu,




On Fri, Jan 27, 2017 at 3:45 PM, Manuranga Perera  wrote:

> 4. Role to User and Role to Group mappings will be will be stored in a DB
>>> schema maintained by carbon
>>>
>> Yes.
>>
> So it's not in LDAP?
>
Yes. The mapping is stored in a local DB, Not in LDAP

Thanks
Isura.

>
>
> On Fri, Jan 27, 2017 at 8:23 AM, Jayanga Kaushalya 
> wrote:
>
>> On Fri, Jan 27, 2017 at 12:18 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Nuwan,
>>>
>>> On Fri, Jan 27, 2017 at 10:40 AM, Nuwan Dias  wrote:
>>>
 Hi,

 In C5, since Groups and Roles are supposed to be treated as two
 different entities, we need to clearly understand how to use them and a bit
 of their implementation details. I'm listing some assumptions and questions
 below, please see if the assumptions are correct and please provide answers
 to the questions too.

 *Assumptions*

 1. Groups are in the LDAP (User Store) and Roles are in the Context of
 Carbon (in a DB schema introduced by WSO2 Products).

>>>
>>> Yes. User Store can be in Database as well. So Groups can exist in User
>>> StoreDB schema as well.
>>>
>>>
 2. Roles are always created through a carbon admin service (MSF4J).

>>>
>>> Yes. We have an OSGi service as well which exposes AuthorizationStore
>>> API as a service.
>>>
>>>
 3. Roles can be attached to users *and* groups.

>>>
>>> Yes.
>>>
>>>
 4. Role to User and Role to Group mappings will be will be stored in a
 DB schema maintained by carbon.

>>>
>>> Yes.
>>>
>>>
 5. Users, Roles and Groups will all have unique identifiers (ids) so
 that products don't have to maintain direct references to the their literal
 values.

>>>
>>> Yes.
>>>
>>> Another addition is Users and Groups can have attributes in C5.
>>> @Jayanga: can you confirm if this is implemented already? If not we need
>>> to track this user story.
>>>
>>
>> Yes we have this capability already implemented.
>>
>>>
>>>

 *Questions*

 1. When saving information to represent "who can do what", do we save
 the role or group? Ex: GET /apis can be performed by [role or group or
 both]?

>>>
>>> Its Roles.
>>> The question "who" represents either user or group - a set of users. The
>>> mapping between resource, action (resource + action = permission) and user
>>> or group is done through roles.
>>>
>>>
>>>
 2. Do we have a concept of "default role(s)" or "internal role(s)"
 which are common to all products?

>>>
>>> So far we have not come across any requirement for "default" roles. But
>>> that would depend on the products I guess. E.g. in APIM we would need
>>> publisher and subscriber roles.
>>>
>>> There will be no concept of "internal" roles because technically roles
>>> are anyway internal to IS. Only groups can be external in a user store.
>>> Earlier we had the concept of "internal" roles because we treated both
>>> groups and roles as roles. So groups were called "external roles" and roles
>>> were called "internal roles".
>>>
>>>
 3. Are roles common across all user stores? If my assumption (1) is
 correct, the answer should be yes I guess.

>>>
>>> Yes.
>>>
>>>


 Thanks,
 NuwanD.

 --
 Nuwan Dias

 Software Architect - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729 <+94%2077%20777%205729>

>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>>
>>> *Johann Dilantha Nallathamby*
>>> Technical Lead & Product Lead of WSO2 Identity Server
>>> Governance Technologies Team
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+9476950*
>>> Blog - *http://nallaa.wordpress.com *
>>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] [C5] Check Whether User Exist in User Stores

[Isura Karunaratne]

Hi Johann, Thanuja,

If we have multiple user stores in C4, it will be looped
UserOperationEventListeners in each user store until authentication success

public boolean doPreAuthenticate(String userName, Object credential,
 UserStoreManager userStoreManager)
throws UserStoreException;


 In this case if need to check whether the user is locked or not, we
had to check user existence in each user store as follows.


String domainName =
userStoreManager.getRealmConfiguration().getUserStoreProperty(UserCoreConstants.RealmConfig.PROPERTY_DOMAIN_NAME);
String usernameWithDomain = UserCoreUtil.addDomainToName(userName, domainName);
boolean isUserExistInCurrentDomain =
userStoreManager.isExistingUser(usernameWithDomain);


How can we handle this in C5?. Is the interceptors called only one time or
will they be called for each domains?


void doPreAuthenticate(Claim claim, Callback[] credentials, String
domainName) throws AuthenticationFailure,
IdentityStoreException;


If this is calling only one time, how to identify the domainName correcly
in interceptor level? If this is calling multiple times we need to a method
for check isUserExististng.



Thanks
Isura



*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/




On Fri, Jan 27, 2017 at 1:07 PM, Johann Nallathamby  wrote:

> Hi Lahiru,
>
> Unless its really required for your business logic you should avoid
> checking if user exists all the time. If user does not exist you will get
> an exception and you can handle it. You should not be compromising best
> case performance. I know we've done this mistake in several places in C4.
> We should be careful in C5.
>
> I will let the others to comment on if there are optimal ways to retrieve
> the user.
>
> Regards,
> Johann.
>
> On Fri, Jan 27, 2017 at 12:58 PM, Lahiru Manohara 
> wrote:
>
>> Hi,
>>
>> We can use getUser method to check whether the user exists in user
>> stores. But do we have any optimized method to do this operation?
>>
>> Best Regards,
>> --
>> *Lahiru Manohara*
>> *Software Engineer*
>> Mobile: +94716561576
>> WSO2 Inc. | http://wso2.com
>> lean.enterprise.middleware
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IAM] [IS6.0.0] Lifecycle support for Identity management scenarios.

[Isura Karunaratne]

Hi all,

We are working on implementing life cycle support for Identity Managment
scenarios in IS 6.0.0. [1] [2].

Following are the identified state charts for different Identity management
scenarios which we are going to support in IS 6.0.0 OOTB.



Abbreviations

LS

Lock State

RPC

Require Password Change

EV

Email Verified

EUV

Email Unverified

SSU

Self Sign Up

UN_EV

Unlocked Email Verified

UN_EUV

Unlocked Email Unverified

UN

Unlocked

UN_IC

Unlocked Invalid Credentials

UN_SSU

Unlocked Self Sign Up

IA

Invalid Answer

UN_IA

Unlocked Invalid Answer

AIPR

Admin Initiated Password Reset

UN_AIPR

Unlocked Admin Initiated PR

DS

Disable state




Self SignUp Feature






Email Verified Feature




Ask Password Feature



Account Lock when Invalid Credentials













Account Lock when Invalid Answers for Security Question













Admin Initiated Password Reset Feature













Admin Lock/Unlock User












Overall Lifecycle














Overall Lifecycle summary








We are planning to reuse the existing lifecycle management feature of APIM
[3]. Appreciate your suggestions and feedbacks on this.



Thanks
Isura.






[1]  [Architecture] Lifecycles for Identity Management
[2] Account Lock/Disable Feature in IS 6.0.0
[3] https://github.com/wso2/carbon-apimgt/tree/C5/lcm






*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.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

[Isura Karunaratne]

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.

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.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] [IS 6.0.0] Email Management Component Implementation

[Isura Karunaratne]

Hi Lahiru,

On Sun, Jan 22, 2017 at 4:40 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
>
> +1 for the directory structure.
>
> We need to support both HTML and text based email templates. Also, there
> should be a way to specify user claims in email templates. We support those
> features  in IS5.3.0.
>
> Thanks
> Isura.
>
>
> 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

Re: [Architecture] Account Lock/Disable Feature in IS 6.0.0

[Isura Karunaratne]

Hi Prabath,


On Fri, Jan 20, 2017 at 4:43 PM, Prabath Siriwardena <prab...@wso2.com>
wrote:

> Hi Isura,
>
> Please find my comment inline...
>
> On Fri, Jan 20, 2017 at 2:02 AM, Isura Karunaratne <is...@wso2.com> wrote:
>
>> Hi all,
>>
>>
>> We are working on implementing account lock/disable features for IS
>> 6.0.0.
>>
>> *Account Lock: *
>>
>>- User *must not *be able to login to the system.
>>- Admin user *can* update the user attributes and assign roles
>>(account is active)
>>- User cannot start a  password recovery flow.
>>
>>
> In summary the user cannot do any actions with the system - but the
> Administrators can.
>
>
>> *Account Disable: *
>>
>>- User *must not* be able to login to the system.
>>- Admin user *can not* update the user attributes and cannot assign
>>roles until enabling the account. (inactive state)
>>- User cannot start a  password recovery flow.
>>
>> Neither the user nor the Administrator can do any actions on this user.
> Special case, the Administrator can enable the user account.
>
>
>>
>>
>> *When will the account be locked?*
>>
>>
>>
>>- Self Signup users until account confirmation
>>
>> This is special status - and we need to identify this status different
> from the account lock. A user in this status can request to resend the
> confirmation code.
>
> Also one (an Administrator) should be able to setup a policy to wipe out
> all the unconfirmed accounts after sometime. Also there can be cases we
> still let unconfirmed users login to the system - but only a limited set of
> functionality is allowed.
>
>>
>>- Try to login with invalid credentials more than configured number
>>of attempts. Then the account will be locked configured amount of time.
>>(Like 5 minutes). This lock time will be increased if the user locked 
>> again
>>based on a configuration.
>>- Provide invalid answers more than configured number of attempts,
>>when password recovery
>>- User onboarding with Email/SMS verification flow.
>>
>> Applies the same comment here - for the self-signup
>
>>
>>- When admin needs to block the user to login to the system
>>- When admin initiated password reset flow starts.
>>
>> We need to identify this states different from the account lock..
>

Since we have multiple states for different scenarios, shall we implement
the state transition (life cycle) like Johann explain in [1]

[1] [Architecture] Lifecycles for Identity Management

Thanks
Isura

>
>>
>> *When will the account be disabled?*
>>
>>
>>
>>
>>
>>- When admin needs to inactivate user.
>>
>>
>>
>> What is the best way handle account disable check? We can do this from a
>> inceptor level, then we need to check account disable in each operation.
>>
>> Thanks
>> Isura.
>>
>>
>>
>>
>>
>> *Isura Dilhara Karunaratne*
>> Senior Software Engineer | WSO2
>> Email: is...@wso2.com
>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>>
>
>
> --
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Mobile : +1 650 625 7950 <(650)%20625-7950>
>
> http://facilelogin.com
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Isura Karunaratne]

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.


> *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

[Architecture] Account Lock/Disable Feature in IS 6.0.0

[Isura Karunaratne]

Hi all,


We are working on implementing account lock/disable features for IS 6.0.0.

*Account Lock: *

   - User *must not *be able to login to the system.
   - Admin user *can* update the user attributes and assign roles (account
   is active)
   - User cannot start a  password recovery flow.

*Account Disable: *

   - User *must not* be able to login to the system.
   - Admin user *can not* update the user attributes and cannot assign
   roles until enabling the account. (inactive state)
   - User cannot start a  password recovery flow.



*When will the account be locked?*



   - Self Signup users until account confirmation
   - Try to login with invalid credentials more than configured number of
   attempts. Then the account will be locked configured amount of time. (Like
   5 minutes). This lock time will be increased if the user locked again based
   on a configuration.
   - Provide invalid answers more than configured number of attempts, when
   password recovery
   - User onboarding with Email/SMS verification flow.
   - When admin needs to block the user to login to the system
   - When admin initiated password reset flow starts.



*When will the account be disabled?*





   - When admin needs to inactivate user.



What is the best way handle account disable check? We can do this from a
inceptor level, then we need to check account disable in each operation.

Thanks
Isura.





*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810 <+94%2077%20225%204810>
Blog : http://isurad.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [IS 6.0.0] [User Portal] Challenge Questions in Self sign-up page of user portal

[Isura Karunaratne]

Hi Nuwan,




On Fri, Jan 20, 2017 at 11:48 AM, Nuwan Dias <nuw...@wso2.com> wrote:

>
>
> On Thu, Jan 19, 2017 at 10:42 AM, Isura Karunaratne <is...@wso2.com>
> wrote:
>
>> Hi,
>>
>> In my opinion, admin defined security questions are more secure than
>> user-defined security questions in general. Because some users may define
>> simple questions and answers which attackers can guess easily.
>>
>
> I don't agree on that :). An admin's questions needs to be generic so that
> they apply to everybody. Ex: "What's your mother's maiden name?". They can
> never ask personalized questions such as "What is the name of the 3rd
> school you attended?" because not everybody has attended 3 or more schools.
> Therefore answers to admin defined questions are very easily guessable
> compared to user-defined/personalized questions.
>
> Yes, users can be lazy and define easy questions, but we can easily get
> around that by putting a simple advice along with a few examples like the
> one above.
>

Agree with you, if all the users are concerned about their security and
provide good questions as you mentioned, but that's not the general
behaviour. We can't guarantee that all users will provide good questions.

Some researchers are also found that better to avoid user defined security
questions [1]


[1]
http://www.passwordresearch.com/files/A%20Review%20of%20Real%20World%20Security%20Questions%20Answers%20-%20PasswordsCon13.pdf

Thanks
Isura.

>
>> Still, most of the users who use Identity Server, use this feature. So, I
>> am -1 to remove feature completely.  We can give following options, so
>> users can decide better option for them.
>>
>>- Email based recovery
>>- Security Question-based recovery
>>- Email + Security Question based recovery.
>>
>>
>> Thanks
>> Isura.
>>
>>
>> *Isura Dilhara Karunaratne*
>> Senior Software Engineer | WSO2
>> Email: is...@wso2.com
>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>>
>> On Thu, Jan 19, 2017 at 9:48 AM, Rushmin Fernando <rush...@wso2.com>
>> wrote:
>>
>>> Hi Ishara,
>>>
>>> Since challenge questions themselves are insecure, customers will not
>>> use only that feature in a production system. So IMO it is not a 'good to
>>> have' option even.
>>>
>>> When I tried to reset my salesfroce password yesterday, they emailed me
>>> a link and it took me to a page with my security questions. So it was an 
>>> *email
>>> + security questions* solution.
>>>
>>> But my guess is they might be using an existing security questions
>>> feature of them.
>>>
>>> In our case, we have still not implemented it. So I'm -1 for
>>> implementing challenge questions.
>>>
>>> On Wed, Jan 18, 2017 at 11:41 PM, Ishara Karunarathna <isha...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 18, 2017 at 11:17 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jan 18, 2017 at 11:12 PM, Ishara Karunarathna <
>>>>> isha...@wso2.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Though challenge question is not secure mechanism this is a basic
>>>>>> stuff client expect from an IAM solution.
>>>>>> And having another recovery mechanism with this can help to make it
>>>>>> strong as well.
>>>>>>
>>>>>> So I'm still doubt on dropping this. And if we are completely
>>>>>> dropping this. We should have first class support for other
>>>>>> recovery mechanisms and well documented on this.
>>>>>>
>>>>>
>>>>> That's the idea right? I was under the impression that we will at
>>>>> least have an email based recovery mechanism in place. If we're saying
>>>>> challenge questions are our primary mode of account recovery, that's not
>>>>> right IMO. AFAIS, challenge questions are 'good to have' and email 
>>>>> recovery
>>>>> is 'must have'.
>>>>>
>>>> Yes challenge question should not be a primary mechanism. But still its
>>>> better to be available in the product.
>>>>
>>>>>
>>>>>> -Ishara
>>>>>>
>>>>>> On Wed, Jan 18, 2017 at 6:2

Re: [Architecture] [Dev] [IS 6.0.0] [User Portal] Challenge Questions in Self sign-up page of user portal

[Isura Karunaratne]

Hi,

In my opinion, admin defined security questions are more secure than
user-defined security questions in general. Because some users may define
simple questions and answers which attackers can guess easily.

Still, most of the users who use Identity Server, use this feature. So, I
am -1 to remove feature completely.  We can give following options, so
users can decide better option for them.

   - Email based recovery
   - Security Question-based recovery
   - Email + Security Question based recovery.


Thanks
Isura.


*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/




On Thu, Jan 19, 2017 at 9:48 AM, Rushmin Fernando  wrote:

> Hi Ishara,
>
> Since challenge questions themselves are insecure, customers will not use
> only that feature in a production system. So IMO it is not a 'good to have'
> option even.
>
> When I tried to reset my salesfroce password yesterday, they emailed me a
> link and it took me to a page with my security questions. So it was an *email
> + security questions* solution.
>
> But my guess is they might be using an existing security questions feature
> of them.
>
> In our case, we have still not implemented it. So I'm -1 for implementing
> challenge questions.
>
> On Wed, Jan 18, 2017 at 11:41 PM, Ishara Karunarathna 
> wrote:
>
>>
>>
>> On Wed, Jan 18, 2017 at 11:17 PM, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Wed, Jan 18, 2017 at 11:12 PM, Ishara Karunarathna 
>>> wrote:
>>>
 Hi All,

 Though challenge question is not secure mechanism this is a basic stuff
 client expect from an IAM solution.
 And having another recovery mechanism with this can help to make it
 strong as well.

 So I'm still doubt on dropping this. And if we are completely dropping
 this. We should have first class support for other
 recovery mechanisms and well documented on this.

>>>
>>> That's the idea right? I was under the impression that we will at least
>>> have an email based recovery mechanism in place. If we're saying challenge
>>> questions are our primary mode of account recovery, that's not right IMO.
>>> AFAIS, challenge questions are 'good to have' and email recovery is 'must
>>> have'.
>>>
>> Yes challenge question should not be a primary mechanism. But still its
>> better to be available in the product.
>>
>>>
 -Ishara

 On Wed, Jan 18, 2017 at 6:21 PM, Danushka Fernando 
 wrote:

> If everyone had it in past and no longer using it, big +1 for removing
> it. Only concern is about existing customers. If we can explain the
> rationale behind removing it we are in clear I guess.
>
> @Sewmini
> Yes there is a reviewed user story for this. But when we discuss about
> some implementation details today, we realized that lot of people had this
> and removed this due to vulnerabilities in it. Hence Indunil started this
> discussion.
>
> Thanks & Regards
> Danushka Fernando
> Senior Software Engineer
> WSO2 inc. http://wso2.com/
> Mobile : +94716332729 <+94%2071%20633%202729>
>
>
>
> On Jan 18, 2017 6:04 PM, "KasunG Gajasinghe"  wrote:
>
>>
>> Security questions are a thing of the past. Google, Facebook they all
>> have removed the security questions based password recovery mechanisms. 
>> [1]
>> [2]  So, +1 to drop this support in IS 6.
>>
>> [1] http://googlesystem.blogspot.com/2014/12/google-drops-su
>> pport-for-security.html
>> [2] https://www.facebook.com/help/community/question/?id=815
>> 382261879187
>>
>> On Wed, Jan 18, 2017 at 5:37 PM, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Wed, Jan 18, 2017 at 5:10 PM, Indunil Upeksha Rathnayake <
>>> indu...@wso2.com> wrote:
>>>
 Hi,

 Currently we are working on implementing C5 user portal in IS.
 Appreciate your suggestions/ideas for the following concerns regarding
 challenge questions.

 *1)  Is it necessary to include challenge questions in IS 6.0.0 as
 a recovery option?*
 Seems like secret questions are neither secure nor reliable enough
 to be used as a account recovery mechanism. And also most of the 
 vendors
 has completely removed support for security questions including 
 google. In
 C5, security question sets will be some what strengthen the recovery 
 and
 makes it hard to guess the questions. But seems like need to consider
 whether it need to be implemented or not.

>>>
>>> I personally have never used a security question to recover any of
>>> the accounts of which I forgot passwords. Its always a recovery through
>>> email or mobile. Therefore I don't see this as 

Re: [Architecture] [Dev] [VOTE] Release WSO2 Identity Server 5.3.0- RC3

[Isura Karunaratne]

Hi,

Tested following features

   - Account Recovery- Notification
   - Account Recovery - Security Question one by one
   - Account Recovery - Security Question at once
   - Recaptcha
   - Password History
   - Self Signup
   - Ask Password
   - User Email Verified
   - Password Pattern
   - Account Lock
   - User Mangement functionality
   - Email template internalization
   - Challenge Question internalization
   - HTML based email template.


These scenarios worked as expected.
[+1] Go ahead and release.

Thanks
Isura



*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/




On Mon, Jan 9, 2017 at 9:33 AM, Dinali Dabarera  wrote:

> Hi,
> I tested the following on the Identity Server 5.3.0-RC3 pack,
>
>- Discovery
>- DCR
>- Form Post
>- Introspection
>- SCIM API
>- User Management
>
> Worked fine without any issues.
> [+] Stable - go ahead and release
>
> On Fri, Jan 6, 2017 at 10:06 PM, Pulasthi Mahawithana 
> wrote:
>
>> Hi All,
>>
>> This is the 3rd Release Candidate of WSO2 Identity Server 5.3.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> This release fixes the following issues:
>>
>> Runtime : https://wso2.org/jira/issues/?filter=13612
>> Analytics : https://wso2.org/jira/issues/?filter=13614
>>
>> Source and distribution
>>
>> Run-time : https://github.com/wso2/product-is/releases/tag/v5.3.0-rc3
>> Analytics : https://github.com/wso2/analytics-is/releases/tag/v5.3.0-
>> rc3
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thanks,
>> - WSO2 Identity Server Team -
>>
>> --
>> *Pulasthi Mahawithana*
>> Senior Software Engineer
>> WSO2 Inc., http://wso2.com/
>> Mobile: +94-71-5179022 <+94%2071%20517%209022>
>> Blog: http://blog.pulasthi.org
>>
>> 
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Dinali Rosemin Dabarera*
> Software Engineer
> WSO2 Lanka (pvt) Ltd.
> Web: http://wso2.com/
> Email : gdrdabar...@gmail.com
> LinkedIn 
> Mobile: +94770198933 <+94%2077%20019%208933>
>
>
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] What are the REST APIs in WSO2IS-5.3.0 that need to be secured?

[Isura Karunaratne]

Hi,


On Thu, Oct 20, 2016 at 1:19 AM, Harsha Thirimanna  wrote:

> If there any REST API that already secured within itself the feature, then
> we have to remove it and use this. As ex : DCR. in DCR we expect user in
> request payload for now and that APIs are not secured. After apply this we
> can remove the user from request payload and rely on this. And same as we
> may have to check other REST APIs whether those are rely on any other
> secure mechanism.
>
> @Isura, Can you please confirm in identity management REST API like
> inforecovery ?
>
Yes. We need to secure recovery APIs and self-registration APIs (
*api/identity/recovery* and *api/identity/user*).

Thanks
Isura

>
> @Ayesha,
> Ishara already test the DCR and you can fix that removing user in payload,
> apply this and test.
>
> *Harsha Thirimanna*
> Associate Tech Lead | WSO2
>
> Email: hars...@wso2.com
> Mob: +94715186770
> Blog: http://harshathirimanna.blogspot.com/
> Twitter: http://twitter.com/harshathirimann
> Linked-In: linked-in: http://www.linkedin.com/pub/
> harsha-thirimanna/10/ab8/122
> 
>
> On Thu, Oct 20, 2016 at 12:34 PM, Ishara Karunarathna 
> wrote:
>
>> Hi Ayesha,
>>
>> This feature provide a authentication layer in front of any unsecured
>> REST APIs. So do we need to test this with all the REST APIs ?
>>
>> -Ishara
>>
>>
>> On Thu, Oct 20, 2016 at 12:05 PM, Ayesha Dissanayaka 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have started testing the"Generic Authentication Mechanism to all the
>>> REST APIs" feature [1] in IS-5.3.0.
>>> Please mention details on REST APIs in IS services which needs to be
>>> secured, so that I can test those APIs with this feature.
>>>
>>> [1] https://wso2.org/jira/browse/IDENTITY-4742
>>>
>>> Thanks!
>>> -Ayesha
>>>
>>> --
>>> *Ayesha Dissanayaka*
>>> Software Engineer,
>>> WSO2, Inc : http://wso2.com
>>> 
>>> 20, Palmgrove Avenue, Colombo 3
>>> E-Mail: aye...@wso2.com 
>>>
>>
>>
>>
>> --
>> 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] [architecture ] [IS-5.3.0] Admin forces password reset for user

[Isura Karunaratne]

Hi Ayesha,

We can extend Ask Password feature we developed in IS 5.3.0 to support this
feature. So, we can send a confirmation email rather than an OTP.

Thanks
Isura


*Isura Dilhara Karunaratne*
Senior Software Engineer | WSO2
Email: is...@wso2.com
Mob : +94 772 254 810
Blog : http://isurad.blogspot.com/




On Mon, Sep 26, 2016 at 10:03 PM, Ayesha Dissanayaka 
wrote:

> Hi,
>
> I have created public jira IDENTITY-5166
>  to track this implementation.
>
> Thanks!
> -Ayesha
>
>
>
> On Mon, Sep 26, 2016 at 5:14 PM, Ayesha Dissanayaka 
> wrote:
>
>> Hi,
>>
>> I have started working on [1], which forces password reset for a user
>> after a administrative password recovery action.
>>
>> Based on the off-line discussion with Darshana, this flow can be as
>> follows.
>>
>>1. User, '*Bob*' forgets password and request administrative person
>>for a password reset action
>>2. Admin person reset the password and provide a new password to *Bob*
>>off-line
>>3. This can be performed using management console
>>4. When *Bob* tries to log-in with newly provided password, login
>>page should prompt password reset UI to *Bob*
>>5. And without changing the password Bob cannot login to the system
>>6. There should be a way to distinguish *user password reset* vs. *admin
>>password reset*.
>>
>> But additionally, there can be enhancements to this flow by sending an
>> OTP in an email to the user, 'Bob' and enforcing password reset by
>> directing to a provided link.
>>
>> What are your thoughts on this?
>>
>> [1] https://redmine.wso2.com/issues/5417
>>
>> Thanks!
>> -Ayesha
>>
>> --
>> *Ayesha Dissanayaka*
>> Software Engineer,
>> WSO2, Inc : http://wso2.com
>> 
>> 20, Palmgrove Avenue, Colombo 3
>> E-Mail: aye...@wso2.com 
>>
>
>
>
> --
> *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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Identity Recovery Rest APIs

[Isura Karunaratne]

Hi all,



On Tue, Jul 12, 2016 at 8:14 AM, Joseph Fonseka <jos...@wso2.com> wrote:

> Hi Isura
>
> A minor suggestions to make the interface intuitive.
>
> * Instead of PUT "recover-password"  introduce a new processing function
> POST "set-password". The parameters can be the same.
>- This will avoid using a PUT for a partial update which actually
> should be a PATCH but in this case processing function is more appropriate.
>

+1. Modifed the swagger file according to this.

 We had the review session with following participants. We could identify
some of the resource paths improvements and error code improvements during
the session. You can find the attached updated swagger file for more
details.


Participants : Prabath, Sanjeewa, Darshana, Harsha, Isura

Thanks
Isura

>
> Thanks
> Jo
>
> On Mon, Jul 11, 2016 at 10:33 AM, Isura Karunaratne <is...@wso2.com>
> wrote:
>
>> Hi Sanjeewa,
>>
>> On Mon, Jul 11, 2016 at 10:24 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
>> wrote:
>>
>>> @Isura,
>>> Can you arrange a review session for this?
>>>
>> Sure. I will arrage.
>>
>> Thanks
>> Isura
>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Thu, Jul 7, 2016 at 5:34 PM, Isura Karunaratne <is...@wso2.com>
>>> wrote:
>>>
>>>>
>>>> Hi all,
>>>>
>>>> Following are the new rest API implementation [1] that we have
>>>> developed for IS 5.3.0 m2 . We are in the process of refactoring and model
>>>> the APIs using swagger. You can find the attached swagger definition that
>>>> we have developed.
>>>>
>>>> Your comments and suggestions are highly appreciated.Recover with
>>>> Notification
>>>>
>>>>-
>>>>
>>>>sendRecoveryNotification() : validate user and returns a new key
>>>>through a notification.
>>>>-
>>>>
>>>>updatePassword() : Updates the password in the system. Need to
>>>>provide the key from notification, new password
>>>>
>>>>
>>>> Recover with Secret Questions
>>>>
>>>>-
>>>>
>>>>intiateUserChallengeQuestion(); ­validate user and returns a
>>>>question to answer with a secret code
>>>>-
>>>>
>>>>verifyUserChallengeAnswer(); validate secret code and answer for
>>>>the question in previous step. Return a new question with new secret 
>>>> until
>>>>the minimum number of questions are answered.
>>>>-
>>>>
>>>>updatePassword(); Updates the password in the system. Need to
>>>>provide the key from notification, new password
>>>>
>>>>
>>>>
>>>> New APIs for Multiple Questions at once
>>>>
>>>>-
>>>>
>>>>getAllChallegeQuestions(); validate user and returns all questions
>>>>to answer with a secret code
>>>>-
>>>>
>>>>validateAllChallengeAnswers(); validate code and all answers and
>>>>return a code if success
>>>>-
>>>>
>>>>updatePassword();Updates the password in the system. Need to
>>>>provide the key from notification, new password
>>>>
>>>>
>>>>
>>>> [1] Identity Management Recovery API improvements
>>>>
>>>>
>>>> --
>>>> Isura Dilhara Karunaratne
>>>> Senior Software Engineer
>>>>
>>>> Mob +94 772 254 810
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779
>>>
>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>
>>>
>>>
>>
>>
>> --
>> Isura Dilhara Karunaratne
>> Senior Software Engineer
>>
>> Mob +94 772 254 810
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * <http://lk.linkedin.com/in/rumeshbandara>*
>
>


-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810


wso2_recovery-api.yaml
Description: application/yaml


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

Re: [Architecture] Identity Recovery Rest APIs

[Isura Karunaratne]

Hi Sanjeewa,

On Mon, Jul 11, 2016 at 10:24 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:

> @Isura,
> Can you arrange a review session for this?
>
Sure. I will arrage.

Thanks
Isura

>
> Thanks,
> sanjeewa.
>
> On Thu, Jul 7, 2016 at 5:34 PM, Isura Karunaratne <is...@wso2.com> wrote:
>
>>
>> Hi all,
>>
>> Following are the new rest API implementation [1] that we have developed
>> for IS 5.3.0 m2 . We are in the process of refactoring and model the APIs
>> using swagger. You can find the attached swagger definition that we have
>> developed.
>>
>> Your comments and suggestions are highly appreciated.Recover with
>> Notification
>>
>>-
>>
>>sendRecoveryNotification() : validate user and returns a new key
>>through a notification.
>>-
>>
>>updatePassword() : Updates the password in the system. Need to
>>provide the key from notification, new password
>>
>>
>> Recover with Secret Questions
>>
>>-
>>
>>intiateUserChallengeQuestion(); ­validate user and returns a question
>>to answer with a secret code
>>-
>>
>>verifyUserChallengeAnswer(); validate secret code and answer for the
>>question in previous step. Return a new question with new secret until the
>>minimum number of questions are answered.
>>-
>>
>>updatePassword(); Updates the password in the system. Need to provide
>>the key from notification, new password
>>
>>
>>
>> New APIs for Multiple Questions at once
>>
>>-
>>
>>getAllChallegeQuestions(); validate user and returns all questions to
>>answer with a secret code
>>-
>>
>>validateAllChallengeAnswers(); validate code and all answers and
>>return a code if success
>>-
>>
>>updatePassword();Updates the password in the system. Need to provide
>>the key from notification, new password
>>
>>
>>
>> [1] Identity Management Recovery API improvements
>>
>>
>> --
>> Isura Dilhara Karunaratne
>> Senior Software Engineer
>>
>> Mob +94 772 254 810
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> <http://sanjeewamalalgoda.blogspot.com/>blog
> :http://sanjeewamalalgoda.blogspot.com/
> <http://sanjeewamalalgoda.blogspot.com/>
>
>
>


-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Identity Recovery Rest APIs

[Isura Karunaratne]

Hi all,

Following are the new rest API implementation [1] that we have developed
for IS 5.3.0 m2 . We are in the process of refactoring and model the APIs
using swagger. You can find the attached swagger definition that we have
developed.

Your comments and suggestions are highly appreciated.Recover with
Notification

   -

   sendRecoveryNotification() : validate user and returns a new key through
   a notification.
   -

   updatePassword() : Updates the password in the system. Need to provide
   the key from notification, new password


Recover with Secret Questions

   -

   intiateUserChallengeQuestion(); ­validate user and returns a question to
   answer with a secret code
   -

   verifyUserChallengeAnswer(); validate secret code and answer for the
   question in previous step. Return a new question with new secret until the
   minimum number of questions are answered.
   -

   updatePassword(); Updates the password in the system. Need to provide
   the key from notification, new password



New APIs for Multiple Questions at once

   -

   getAllChallegeQuestions(); validate user and returns all questions to
   answer with a secret code
   -

   validateAllChallengeAnswers(); validate code and all answers and return
   a code if success
   -

   updatePassword();Updates the password in the system. Need to provide the
   key from notification, new password



[1] Identity Management Recovery API improvements


-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810


swagger.is.recovery.yaml
Description: application/yaml
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] Supporting user information recovery scenarios in IS user portal

[Isura Karunaratne]

Hi,

We already have a rest API implementation for self-registration.

+1 for implementing self-registration through SCIM. I have following
concern when implementing self-registration through SCIM,


   - How to identify SCIM self-registration request over normal admin
   provisioning request?
   - It is required to support SAAS authentication (users in super tenant
   should be able to add users to other tenants) for self-registration
   feature. AFAIR, Currently, SCIM requires tenant wise authentication.


We can use following to overcome above,


   - Currently, we are assigning identity internal role for self-registered
   users. So, we can identify the self-registration provisioning SCIM request
   from internal/identity role. So, we can create a new Event handler to
   support this feature.
   -  We can support SCIM self-registration for authenticated tenant space
   and we will keep the existing rest API implementation to support SAAS
   authentication.


Thanks
Isura

On Sat, Jun 25, 2016 at 1:53 AM, Johann Nallathamby <joh...@wso2.com> wrote:

> @Isura,
>
> Can we use SCIM to implement self sign-up instead of introducing a new
> self-sign up REST API? Can we extend the SCIM API to support the options we
> need for the two self sign-up scenarios Malithi has mentioned in her
> initial mail?
>
> I think if it's possible we should go for it. If the restriction on using
> one API is because we want to know whether user is doing a self-sign up or
> getting created by an admin user, then I think it is wrong. Knowing who is
> the actor who is creating the user, self or admin, is necessary for access
> control only. That should be not a concern for the API. That should be
> handled before hitting the API. We have discussed and handled a similar
> requirement for our UserIdentityMangementAdminService which is a SOAP
> service using two axis2 handlers. Farasath will send a mail on this I think.
>
> I think we can discuss and see if it's possible to use SCIM to handle both
> these scenarios.
>
>
> On Wed, Jun 8, 2016 at 1:07 PM, Darshana Gunawardana <darsh...@wso2.com>
> wrote:
>
>> Hi Malithi,
>>
>> On Wed, Jun 8, 2016 at 10:28 AM, Malithi Edirisinghe <malit...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> I have following concern with regard to moving the account recovery web
>>> application from OOTB supported KAPTCHA to google reCaptcha.
>>>
>>> As noted at [1], we should have an API key pair. Thus, we will not be
>>> able to enable this for the webapp by default (with the fresh IS server
>>> pack).
>>>
>>
>> There will be a default key pair that can be used in the default pack.
>>
>> Further, previously, captcha validation is a must for recovery API calls(
>>> Ex: Password Recovery).
>>> So does the new implementation enforce that verification?
>>> If it does, we would also not be able to view those recovery options by
>>> default.
>>>
>>
>> As per new captcha implementation, captcha enforcement is decoupled from
>> the backend API and new generic filter take care of handling the captcha.
>>
>> So any web app don't have to invoke additional APIs to handle captcha.
>>
>> Regards,
>> Darshana.
>>
>>>
>>> @Isura,
>>> Could you please initiate a thread on the design of the new Identity
>>> Management APIs
>>>
>>> [1][Architecture] [IS] Support for Google reCapth
>>>
>>> Thanks,
>>> Malithi.
>>>
>>> On Tue, Jun 7, 2016 at 11:33 AM, Thanuja Jayasinghe <than...@wso2.com>
>>> wrote:
>>>
>>>> Hi Omindu,
>>>>
>>>> Yes. We can't use reCaptcha without internet. But the chance of having
>>>> Bots attack from a internal network is very less. So we can either disable
>>>> reCaptcha when server is not connect to the internet or have the old
>>>> captcha implementation.
>>>>
>>>> +1 for keep the existing captcha implementation. But we have to modify
>>>> login, self-registration and recovery flows to add captcha/reCaptcha in a
>>>> pluggable manner.
>>>>
>>>> Thanks,
>>>> Thanuja.
>>>>
>>>> On Tue, Jun 7, 2016 at 11:14 AM, Isura Karunaratne <is...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, Jun 7, 2016 at 10:47 AM, Omindu Rathnaweera <omi...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Isura,
>>>>>>
>>>>>> Since reCaptcha requires to call Goo

Re: [Architecture] [IS] Block brute force attacks on password recovery flows

[Isura Karunaratne]

Hi Thanuja,

On Mon, Jun 20, 2016 at 1:35 PM, Thanuja Jayasinghe 
wrote:

> Hi All,
>
> I'm working on $subject.
>
> We are planning to prevent this flow from brute force attacks by enabling
> followings,
>
>1. Enable captcha/reCaptcha after n failed attempts
>2. Lock the account after n failed attempts for a period of time
>
>
> *How to track failed attempts?*
>
> We already have a "http://wso2.org/claims/identity/failedLoginAttempts; claim
> which used in the login flow to track failed login attempts. Since this is
> a different flow, using the same claim to track the failed password reset
> attempts will lead to unintended situations. (Ex: After n number of
> failed attempts in the login flow, a user may try to reset the password. In
> this case, the user will see captcha if the number of failed attempts
> reached to the maximum. But since this is the first time which the user
> tries to reset the password, captcha is redundant.)
>
> So we will introduce a new claim call "
> http://wso2.org/claims/identity/failedPasswordResetAttempts; to track
> this.
>

+1 for having a seperate claiam for tracking password reset faliled
attempts since it is different from login Attempts.

>
>
> *Implementation*
>
> *Enable captcha/reCaptcha after n failed attempts* -  New Captcha
> connector will introduce to handle this. The configuration of the connector
> UI will allow modifying connector according to the requirements.
>

> *Lock the account after n failed attempts for a period of time *- Account
> lock will handle from the identity recovery rest API logic. Also 
> "PRE_SET_USER_CLAIMS"
> and "POST_SET_USER_CLAIMS" events will be reused to send notifications in
> case of account lock.
>
Where can we define the lock time?. Is it a new configuration or same
configuration used when account lock with invalid credentials?

Thanks
Isura.

>
> Appreciate your input.
>
> Thanks,
> Thanuja
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev]Force Password Reset and Password History validation

[Isura Karunaratne]

Hi Dulanja,

On Mon, Jun 20, 2016 at 12:14 PM, Dulanja Liyanage <dula...@wso2.com> wrote:

>
>
> On Mon, Jun 20, 2016 at 12:11 PM, Dulanja Liyanage <dula...@wso2.com>
> wrote:
>
>>
>>
>> On Mon, Jun 20, 2016 at 10:52 AM, Isura Karunaratne <is...@wso2.com>
>> wrote:
>>
>>> HI all,
>>>
>>> I am working on $subject for WSO2 Identity Sever 5.3.0 release.
>>> Following are the currently identified improvements,
>>>
>>>
>>>- Password History -
>>>
>>> Last 'n' number of passwords need to be maintained in user's history.
>>> When user updates his password we don't allow him to choose one of these
>>> 'n' passwords again.
>>>
>>>
>>>- Periodic Password Reset -
>>>
>>> Force the user to periodically (configurable period) reset his password.
>>> When doing this we need to leverage the password history feature as well.
>>>
>>>
> There can be a requirement where the system forces the user to change the
> password, but at the same time give him the option to use the old password.
> I've seen some financial organizations doing this.
>
If we are going to support this cofiguration, I think it is better to user
same hashing method.


>
>>>
>>> CREATE TABLE IF NOT EXISTS idn_password_history_data
>>>  (
>>>   user_name   *VARCHAR*(255) NOT NULL,
>>>   user_domain *VARCHAR*(255) NOT NULL,
>>>   tenant_id   *INTEGER* DEFAULT -1,
>>>   hash*VARCHAR*(255) NOT NULL,
>>>   time_created *TIMESTAMP* NOT NULL DEFAULT
>>> CURRENT_TIMESTAMP,
>>>   PRIMARY KEY (user_name,user_domain,tenant_id,
>>> hash),
>>>  )
>>>
>>>
>>> All the passwords which are supposed to store in this table are old
>>> passwords (expired).
>>>
>>> - I think we don't need to use the same  password hashing algorithm
>>> (with or without salted value) which is defined user-mgt.xml for password
>>> history validation.
>>>
>>
>> IMO using the same hashing algo is cleaner. Isn't the current password
>> also stored in this table? If stored, it's mandatory to use salting.
>>
> Current password will not store in the new table.

>
>>
>>> - admin users can change other user's passwords without giving their old
>>> passwords. In that case, how can we find the old password hash value to
>>> store for password history validation?
>>>
>>>
>>> Your comments and suggestions are highly appreciated.
>>>
>>> Thanks
>>> Isura.
>>>
>>>
>>> Isura Dilhara Karunaratne
>>> Senior Software Engineer
>>>
>>> Mob +94 772 254 810
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Dulanja Liyanage
>> Lead, Platform Security Team
>> WSO2 Inc.
>>
>
>
>
> --
> Thanks & Regards,
> Dulanja Liyanage
> Lead, Platform Security Team
> WSO2 Inc.
>



-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev]Force Password Reset and Password History validation

[Isura Karunaratne]

HI all,

I am working on $subject for WSO2 Identity Sever 5.3.0 release. Following
are the currently identified improvements,


   - Password History -

Last 'n' number of passwords need to be maintained in user's history. When
user updates his password we don't allow him to choose one of these 'n'
passwords again.


   - Periodic Password Reset -

Force the user to periodically (configurable period) reset his password.
When doing this we need to leverage the password history feature as well.


CREATE TABLE IF NOT EXISTS idn_password_history_data
 (
  user_name   *VARCHAR*(255) NOT NULL,
  user_domain *VARCHAR*(255) NOT NULL,
  tenant_id   *INTEGER* DEFAULT -1,
  hash*VARCHAR*(255) NOT NULL,
  time_created *TIMESTAMP* NOT NULL DEFAULT
CURRENT_TIMESTAMP,
  PRIMARY KEY (user_name,user_domain,tenant_id,hash)
,
 )


All the passwords which are supposed to store in this table are old
passwords (expired).

- I think we don't need to use the same  password hashing algorithm (with
or without salted value) which is defined user-mgt.xml for password history
validation.
- admin users can change other user's passwords without giving their old
passwords. In that case, how can we find the old password hash value to
store for password history validation?


Your comments and suggestions are highly appreciated.

Thanks
Isura.


Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Identity Management Recovery API improvements.

[Isura Karunaratne]

Hi,

On Tue, Jun 14, 2016 at 12:19 AM, Gayan Gunawardana <ga...@wso2.com> wrote:

> Hi Isura,
>
> I have few suggestions.
>
> [1] At the end of both flaws (Recover with Notification, Recover with
> Secret Questions) is it possible to send notification (acknowledgment) to
> end user to inform about password update. This will give good experience to
> end user and on the other hand biggest problem with "Recover with Secret
> Questions" is someone else can guess answers for security questions so
> sending notification at the end of password recovery is important.
>

This is already done. If you reest a password, you will get a notificatoin
saying "Your password is successfully reset"

>
> [2] How can we support custom flaws ? For an example
>
> intiateUserChallengeQuestion()
> verifyUserChallengeAnswer()
> sendRecoveryNotification()
> updatePassword()
>

Currenlty, we don't support custom flows.

>
> [3] What are the extension points we have for this implementation ? For an
> example, Instead of sending recovery notification via email user need to
> enter pin which is sent to his mobile.
>

Notificaton sending has the extentison points to support SMS based recovery.

Thanks
Isura

>
> Thanks,
> Gayan
>
>
> On Thu, Jun 9, 2016 at 11:06 AM, Isura Karunaratne <is...@wso2.com> wrote:
>
>> Hi,
>>
>> On Thu, Jun 9, 2016 at 10:53 AM, Harsha Thirimanna <hars...@wso2.com>
>> wrote:
>>
>>> Hi Isura,
>>>
>>> Any detail about the error response with relevant error codes ?
>>>
>>
>> We have developed error codes for relevant error scenarios, I will update
>> the docs with error code.
>>
>>
>>>
>>>
>>>
>>> *Harsha Thirimanna*
>>> Associate Tech Lead; WSO2, Inc.; http://wso2.com
>>> * <http://www.apache.org/>*
>>> *email: **hars...@wso2.com* <az...@wso2.com>* cell: +94 71 5186770 *
>>> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>*
>>> *harshathirimannlinked-in: **http:
>>> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
>>> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>*
>>>
>>> *Lean . Enterprise . Middleware*
>>>
>>>
>>> On Thu, Jun 9, 2016 at 10:46 AM, Dilan Udara Ariyaratne <dil...@wso2.com
>>> > wrote:
>>>
>>>> Hi Isura,
>>>>
>>>> According to the REST API Guidelines that we have defined across all
>>>> the products,
>>>> following suggestions can be made regarding the resource paths that you
>>>> have proposed.
>>>>
>>>> [1] Base-path "accountrecovery" has two words in it and they can be
>>>> separated by a dash, i.e. as "account-recovery".
>>>> [2] It seems that path "rest" does not make any sense as a resource, so
>>>> it can be removed.
>>>> [3] Also, all the underscore signs included in processiong-functions
>>>> like "reset_password" and resource-paths like "security_questions_response"
>>>> could be replaced with a dash (-).
>>>>
>>>
>> Thanks for the infomation. I will modify the apis based on your
>> suggetions.
>>
>> Thanks
>> Isura
>>
>>>
>>>> Regards,
>>>> Dilan.
>>>>
>>>> *Dilan U. Ariyaratne*
>>>> Senior Software Engineer
>>>> WSO2 Inc. <http://wso2.com/>
>>>> Mobile: +94766405580 <%2B94766405580>
>>>> lean . enterprise . middleware
>>>>
>>>>
>>>> On Wed, Jun 8, 2016 at 1:02 PM, Isura Karunaratne <is...@wso2.com>
>>>> wrote:
>>>>
>>>>> Identity Management Recovery API improvements.
>>>>>
>>>>> In Identity Server 5.3.0, we are going to implement Identity
>>>>> Management recovery APIs as rest resources. In current implementations of
>>>>> IS5.0.0, IS5.1.0 we have soap APIs for recovery scenarios. [1].
>>>>>
>>>>> Captcha validation is coupled with recovery flows in existing soap API
>>>>> implementation and we have improved Java API to decouple to the captcha
>>>>> validation from recovery flows in new implementations. [4]
>>>>> Existing soap APIs.Recover with Notification [2]
>>>>>
>>>>>-
>>>>>
>>>>>getCaptcha() -­ Generates a captcha.
>>&

Re: [Architecture] Identity Management Recovery API improvements.

[Isura Karunaratne]

Hi,

On Thu, Jun 9, 2016 at 10:53 AM, Harsha Thirimanna <hars...@wso2.com> wrote:

> Hi Isura,
>
> Any detail about the error response with relevant error codes ?
>

We have developed error codes for relevant error scenarios, I will update
the docs with error code.


>
>
>
> *Harsha Thirimanna*
> Associate Tech Lead; WSO2, Inc.; http://wso2.com
> * <http://www.apache.org/>*
> *email: **hars...@wso2.com* <az...@wso2.com>* cell: +94 71 5186770 *
> *twitter: **http://twitter.com/ <http://twitter.com/afkham_azeez>*
> *harshathirimannlinked-in: **http:
> <http://lk.linkedin.com/in/afkhamazeez>**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
> <http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122>*
>
> *Lean . Enterprise . Middleware*
>
>
> On Thu, Jun 9, 2016 at 10:46 AM, Dilan Udara Ariyaratne <dil...@wso2.com>
> wrote:
>
>> Hi Isura,
>>
>> According to the REST API Guidelines that we have defined across all the
>> products,
>> following suggestions can be made regarding the resource paths that you
>> have proposed.
>>
>> [1] Base-path "accountrecovery" has two words in it and they can be
>> separated by a dash, i.e. as "account-recovery".
>> [2] It seems that path "rest" does not make any sense as a resource, so
>> it can be removed.
>> [3] Also, all the underscore signs included in processiong-functions like
>> "reset_password" and resource-paths like "security_questions_response"
>> could be replaced with a dash (-).
>>
>
Thanks for the infomation. I will modify the apis based on your suggetions.

Thanks
Isura

>
>> Regards,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Wed, Jun 8, 2016 at 1:02 PM, Isura Karunaratne <is...@wso2.com> wrote:
>>
>>> Identity Management Recovery API improvements.
>>>
>>> In Identity Server 5.3.0, we are going to implement Identity Management
>>> recovery APIs as rest resources. In current implementations of IS5.0.0,
>>> IS5.1.0 we have soap APIs for recovery scenarios. [1].
>>>
>>> Captcha validation is coupled with recovery flows in existing soap API
>>> implementation and we have improved Java API to decouple to the captcha
>>> validation from recovery flows in new implementations. [4]
>>> Existing soap APIs.Recover with Notification [2]
>>>
>>>-
>>>
>>>getCaptcha() -­ Generates a captcha.
>>>-
>>>
>>>verifyUser() -­ Validates the captcha answer and username and
>>>returns a new key.
>>>-
>>>
>>>sendRecoveryNotification() -­ Send an email notification with a
>>>confirmation code to the user. Need to provide the key from the previous
>>>call.
>>>-
>>>
>>>getCaptcha() ­- Generates a captcha when the user clicks on the URL.
>>>-
>>>
>>>verifyConfirmationCode() -­ Validates the captcha answer and
>>>confirmation code. This returns a key.
>>>-
>>>
>>>updatePassword -­ Updates the password in the system. Need to
>>>provide the key from the previous call, new password and returns the 
>>> status
>>>of the update, true or false.
>>>
>>> Recover with Secret Questions[3]
>>>
>>>-
>>>
>>>getCaptcha() ­- Generates a captcha.
>>>-
>>>
>>>verifyUser() ­- Validates the captcha answer and username and
>>>returns a new key.
>>>-
>>>
>>>getUserChallengeQuestionIds() ­- Retrieve the claim URI IDs
>>>specified for the user with the generated key. Need to provide the key 
>>> from
>>>the previous call.
>>>-
>>>
>>>getUserChallengeQuestion() ­- Retrieve the user’s challenge question
>>>for the specified claim URI ID from the previous call. Need to provide 
>>> the
>>>key from the previous call.
>>>-
>>>
>>>verifyUserChallengeAnswer() ­- Validates the answer and confirmation
>>>code for the specified question. Need to provide the key from the 
>>> previous
>>>call.
>>>-
>>>
>>>updatePassword() ­- Updates the password in the system. Need to
>>>provide th

Re: [Architecture] [IS] Supporting user information recovery scenarios in IS user portal

[Isura Karunaratne]

Hi Malithi,


On Wed, Jun 8, 2016 at 10:28 AM, Malithi Edirisinghe <malit...@wso2.com>
wrote:

> Hi All,
>
> I have following concern with regard to moving the account recovery web
> application from OOTB supported KAPTCHA to google reCaptcha.
>
> As noted at [1], we should have an API key pair. Thus, we will not be able
> to enable this for the webapp by default (with the fresh IS server pack).
> Further, previously, captcha validation is a must for recovery API calls(
> Ex: Password Recovery).
> So does the new implementation enforce that verification?
> If it does, we would also not be able to view those recovery options by
> default.
>
> @Isura,
> Could you please initiate a thread on the design of the new Identity
> Management APIs
>

You can refer new thread of Identity Management Rest APIs  from [1]



[1]  [Architecture] Identity Management Recovery API improvements.

Thanks
Isura


> [1][Architecture] [IS] Support for Google reCapth
>
> Thanks,
> Malithi.
>
> On Tue, Jun 7, 2016 at 11:33 AM, Thanuja Jayasinghe <than...@wso2.com>
> wrote:
>
>> Hi Omindu,
>>
>> Yes. We can't use reCaptcha without internet. But the chance of having
>> Bots attack from a internal network is very less. So we can either disable
>> reCaptcha when server is not connect to the internet or have the old
>> captcha implementation.
>>
>> +1 for keep the existing captcha implementation. But we have to modify
>> login, self-registration and recovery flows to add captcha/reCaptcha in a
>> pluggable manner.
>>
>> Thanks,
>> Thanuja.
>>
>> On Tue, Jun 7, 2016 at 11:14 AM, Isura Karunaratne <is...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Jun 7, 2016 at 10:47 AM, Omindu Rathnaweera <omi...@wso2.com>
>>> wrote:
>>>
>>>> Hi Isura,
>>>>
>>>> Since reCaptcha requires to call Google's services for captcha
>>>> generation and validation, we won't be able to use the dashboard with
>>>> captcha when we are running IS in an environment without internet
>>>> connectivity. I'm assuming we are not shipping the old captcha
>>>> implementation in 5.3.0 so a user will not be able to switch to an
>>>> internally managed captcha implementation with a simple config change.
>>>>
>>>> It'll be good if we can make the old captcha implementation (or a
>>>> similar implementation) available (by means of an extension or a sample
>>>> maybe ?) so a user can switch to an internally managed captcha model
>>>> without much work. WDYT ?
>>>>
>>>
>>> +1. but, we better to decouple old captcha implementation with recovery
>>> flows.
>>>
>>> Thanks
>>> Isura
>>>
>>>
>>>> Regards,
>>>> Omindu.
>>>>
>>>> On Sun, Jun 5, 2016 at 12:35 PM, Malithi Edirisinghe <malit...@wso2.com
>>>> > wrote:
>>>>
>>>>> Hi Isura,
>>>>>
>>>>> Noted.
>>>>>
>>>>> I've got one more concern.
>>>>> Initially, as you may have noted in the top most mail, recovery
>>>>> scenarios were to be supported in the login page of the end user
>>>>> dashboard in IS. But in a consecutive discussion it was highlighted that
>>>>> these options should be provided in the default SSO login page. Thus, upon
>>>>> a successful recovery or registration, the flow should be as below.
>>>>>
>>>>>1. End user will be redirected to the login page.
>>>>>2. End user will enter the credentials
>>>>>3. End user is authenticated and upon successful authentication
>>>>>user will be redirected to the Service Provider application (Ex: ACS 
>>>>> url of
>>>>>the SP).
>>>>>
>>>>> So at the moment, we are using the param 'sessionDataKey' to map the
>>>>> server session across modules, which can be used even here to retrieve the
>>>>> respective Service Provider who initiated the flow. But, when it comes to
>>>>> recovery with notifications there is no parameter being communicated to
>>>>> identify the respective Service Provider. Can we please address this also,
>>>>> along with this effort ?
>>>>>
>>>>> Thanks,
>>>>> Malithi.
>>>>>
>>>>> On Sun, Jun 5, 2016 at 8:39 AM, Isura Karunaratne <is...@wso2.com>
>>&

[Architecture] Identity Management Recovery API improvements.

[Isura Karunaratne]

Identity Management Recovery API improvements.

In Identity Server 5.3.0, we are going to implement Identity Management
recovery APIs as rest resources. In current implementations of IS5.0.0,
IS5.1.0 we have soap APIs for recovery scenarios. [1].

Captcha validation is coupled with recovery flows in existing soap API
implementation and we have improved Java API to decouple to the captcha
validation from recovery flows in new implementations. [4]
Existing soap APIs.Recover with Notification [2]

   -

   getCaptcha() -­ Generates a captcha.
   -

   verifyUser() -­ Validates the captcha answer and username and returns a
   new key.
   -

   sendRecoveryNotification() -­ Send an email notification with a
   confirmation code to the user. Need to provide the key from the previous
   call.
   -

   getCaptcha() ­- Generates a captcha when the user clicks on the URL.
   -

   verifyConfirmationCode() -­ Validates the captcha answer and
   confirmation code. This returns a key.
   -

   updatePassword -­ Updates the password in the system. Need to provide
   the key from the previous call, new password and returns the status of the
   update, true or false.

Recover with Secret Questions[3]

   -

   getCaptcha() ­- Generates a captcha.
   -

   verifyUser() ­- Validates the captcha answer and username and returns a
   new key.
   -

   getUserChallengeQuestionIds() ­- Retrieve the claim URI IDs specified
   for the user with the generated key. Need to provide the key from the
   previous call.
   -

   getUserChallengeQuestion() ­- Retrieve the user’s challenge question for
   the specified claim URI ID from the previous call. Need to provide the key
   from the previous call.
   -

   verifyUserChallengeAnswer() ­- Validates the answer and confirmation
   code for the specified question. Need to provide the key from the previous
   call.
   -

   updatePassword() ­- Updates the password in the system. Need to provide
   the key from the previous call, the new password and return the status of
   the update, i.e. true or false.





New APIs
Recover with Notification

   -

   sendRecoveryNotification() : validate user and returns a new key through
   a notification.
   -

   updatePassword() : Updates the password in the system. Need to provide
   the key from notification, new password


Recover with Secret Questions

   -

   intiateUserChallengeQuestion(); ­validate user and returns a question to
   answer with a secret code
   -

   verifyUserChallengeAnswer(); validate secret code and answer for the
   question in previous step. Return a new question with new secret until
   minimum number of questions are answered.
   -

   updatePassword(); Updates the password in the system. Need to provide
   the key from notification, new password



New APIs for Multiple Questions at once

   -

   getAllChallegeQuestions(); validate user and returns all questions to
   answer with a secret code
   -

   validateAllChallengeAnswers(); validate code and all answers and return
   a code if success
   -

   updatePassword();Updates the password in the system. Need to provide the
   key from notification, new password











[1] https://docs.wso2.com/display/IS510/Password+Recovery

[2]
https://docs.wso2.com/display/IS510/Password+Recovery#PasswordRecovery-Recoveryusingnotifications

[3]
https://docs.wso2.com/display/IS510/Password+Recovery#PasswordRecovery-Recoveryusingchallengequestions

[4] [Architecture] Decouple capcha validation from Recovery flows



Sample Requests
Send Email Notification

POST accountrecovery/rest/notification/notify



Request Body

 {

"userName": "testuser",

"tenantDomain": "carbon.super",

 "userStoreDomain": "PRIMARY"

}


If notifications are internally managed,

Response Body

HTTP 200


If notifications are externally managed,

Response Body

{

"user": {

"userName": "testuser",

"userStoreDomain": "PRIMARY",

"tenantDomain": "carbon.super"

},

"key": "f75da810-3478-47f4-80e5-c37556392015"

}





*Reset Password.*

PUT /accountrecovery/rest/notification/reset_password

Request Body

{

"user": {

"userName": "test",

"userStoreDomain": "PRIMARY",

"tenantDomain": "carbon.super"

},

"code": "e4d6041b-2ea7-4dc1-9ae2-b8e9686e1d12",

"password": "12345"

}


Response Body

HTTP 200





Initiate User Challenge Question

PUT /accountrecovery/rest/questions/initiate



Request Body

{

"userName": "admin",

"userStoreDomain": "PRIMARY",

"tenantDomain": "carbon.super"

}



Response body

{

   "question": "City where you were born ?",

   "questionSetId": "http://wso2.org/claims/challengeQuestion1;,

   "code": "786f63b6-d0b7-4bd7-991e-12e97e4602e3",

   "status": "INCOMPLETE"

}




Validate User Challenge Question,

POST /accountrecovery/security_questions_response

Request Body

{

"user": {

"userName": "admin",

"userStoreDomain": "PRIMARY",

"tenantDomain": "carbon.super"

},

"key": 

Re: [Architecture] Decouple capcha validation from Recovery flows

[Isura Karunaratne]

On Mon, May 16, 2016 at 10:34 AM, Johann Nallathamby <joh...@wso2.com>
wrote:

>
>
> On Mon, May 16, 2016 at 10:25 AM, Isura Karunaratne <is...@wso2.com>
> wrote:
>
>> Hi,
>>
>> We are planning to expose recovery APIS in IS 5.3.0 as rest APIS. And
>> also, we are trying to reduce the complexity and improve the performance in
>> existing recovery java APIs as well.
>>
>> Currently, we have two ways of password recovery methods,
>>
>>
>>- Recover with a notification
>>- Recover with secret questions.
>>
>> *Recover with a notification*
>>
>> It is required to go through following sequences to recover password
>> using an email in existing APIs
>>
>> *getCaptcha*() -­ Generates a captcha.
>> *verifyUser*() -­ Validates the captcha answer and username and returns
>> a new key.
>> *sendRecoveryNotification*() -­ Send an email notification with a
>> confirmation code to the user. Need to provide the key from the previous
>> call.
>> *getCaptcha*() ­- Generates a captcha when the user clicks on the URL.
>> *verifyConfirmationCode*() -­ Validates the captcha answer and
>> confirmation code. This returns a key.
>> *updatePassword* -­ Updates the password in the system. Need to provide
>> the key from the previous call, new password and returns the status of the
>> update, true or false.
>>
>>
>>
>> *Recover with Secret Questions*
>>
>> It is required to go through following sequences to recover password
>> using a secret quesitons in existing APIs
>>
>> *getCaptcha*() ­- Generates a captcha.
>> *verifyUser*() ­- Validates the captcha answer and username and returns
>> a new key.
>> *getUserChallengeQuestionIds*() ­- Retrieve the cliam URI IDs specified
>> for the user with the generated key. Need to provide the key from the
>> previous call.
>> *getUserChallengeQuestion*() ­- Retrieve the user’s challenge question
>> for the specified claim URI ID from the previous call. Need to provide the
>> key from the previous call.
>> *verifyUserChallengeAnswer*() ­- Validates the answer and confirmation
>> code for the specified question. Need to provide the key from the previous
>> call.
>> *updatePassword*() ­- Updates the password in the system. Need to
>> provide the key from the previous call, the new password and return the
>> status of the update, i.e. true or false.
>>
>>
>>
>>
>> Currenlty, we are using kaptcha as the captcha generation engine and in
>> IS5.3.0 we are planning to support reCaptcha[1] instead of kapcha.
>>
>> In both of above recovery scenarios,
>>
>> If we manage captcha validation internally, captcha validation is tightly
>> coupled with the recovery sequences. In 5.3.0, We are planning to decouple
>> the captcha validation with recovery APIs.
>> So, captcha validation should be done by the application.
>>
>
> In IS 5.3.0 by application I guess you also mean the account recovery
> webapp which will be shipped with IS for OOTB account recovery. So
> basically the captcha validation would happen between the user recovery
> webapp and the re-captcha service instead of coming to our backend service
> APIs. Right ?
>
>  Yes.

Thanks
Isura

>
>> WDYT?
>>
>>
>> Thanks
>> Isura
>>
>>
>>
>> [1] https://www.google.com/recaptcha/intro/index.html
>> --
>> Isura Dilhara Karunaratne
>> Senior Software Engineer
>>
>> Mob +94 772 254 810
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>



-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Decouple capcha validation from Recovery flows

[Isura Karunaratne]

Hi,

We are planning to expose recovery APIS in IS 5.3.0 as rest APIS. And also,
we are trying to reduce the complexity and improve the performance in
existing recovery java APIs as well.

Currently, we have two ways of password recovery methods,


   - Recover with a notification
   - Recover with secret questions.

*Recover with a notification*

It is required to go through following sequences to recover password using
an email in existing APIs

*getCaptcha*() -­ Generates a captcha.
*verifyUser*() -­ Validates the captcha answer and username and returns a
new key.
*sendRecoveryNotification*() -­ Send an email notification with a
confirmation code to the user. Need to provide the key from the previous
call.
*getCaptcha*() ­- Generates a captcha when the user clicks on the URL.
*verifyConfirmationCode*() -­ Validates the captcha answer and confirmation
code. This returns a key.
*updatePassword* -­ Updates the password in the system. Need to provide the
key from the previous call, new password and returns the status of the
update, true or false.



*Recover with Secret Questions*

It is required to go through following sequences to recover password using
a secret quesitons in existing APIs

*getCaptcha*() ­- Generates a captcha.
*verifyUser*() ­- Validates the captcha answer and username and returns a
new key.
*getUserChallengeQuestionIds*() ­- Retrieve the cliam URI IDs specified for
the user with the generated key. Need to provide the key from the previous
call.
*getUserChallengeQuestion*() ­- Retrieve the user’s challenge question for
the specified claim URI ID from the previous call. Need to provide the key
from the previous call.
*verifyUserChallengeAnswer*() ­- Validates the answer and confirmation code
for the specified question. Need to provide the key from the previous call.
*updatePassword*() ­- Updates the password in the system. Need to provide
the key from the previous call, the new password and return the status of
the update, i.e. true or false.




Currenlty, we are using kaptcha as the captcha generation engine and in
IS5.3.0 we are planning to support reCaptcha[1] instead of kapcha.

In both of above recovery scenarios,

If we manage captcha validation internally, captcha validation is tightly
coupled with the recovery sequences. In 5.3.0, We are planning to decouple
the captcha validation with recovery APIs.
So, captcha validation should be done by the application.

WDYT?


Thanks
Isura



[1] https://www.google.com/recaptcha/intro/index.html
-- 
Isura Dilhara Karunaratne
Senior Software Engineer

Mob +94 772 254 810
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture