Re: [Architecture] [Dev] Binding access token to the browser for new IAM Portal Applications

[Thanuja Jayasinghe]

Hi Dinali,

Please refer "Access Token Binding Type" row in [1].

[1]
https://is.docs.wso2.com/en/5.10.0/learn/configuring-oauth2-openid-connect-single-sign-on/

Thanks,
Thanuja

On Tue, Mar 24, 2020 at 8:40 PM Dinali Dabarera  wrote:

> Hi all,
>
> Do we have an official public documents related to this approach,  the
> token binding mechanism used and other information?
>
> Thank you!
> Dinali
>
> On Wed, Nov 20, 2019 at 7:55 PM Janak Amarasena  wrote:
>
>> Hi All,
>>
>> Currently, there is an OAuth2 Spec[1] under development with the key
>> intention of sender-constraining OAuth 2.0 tokens via a proof-of-possession
>> mechanism. Few takeaways from that which we could also use.
>> We could introduce a new *token_type*[2] (like
>> token_type=bound+cookie) for the cookie bound access token instead of the
>> current bearer token as these tokens should be processed in a different way
>> than the normal bearer tokens.
>> Also if the service provider supports multiple token types we can let the
>> application request a token type it wants by indicating it in some
>> parameter when the application initiates a token requesting flow.
>>
>> [1] - https://tools.ietf.org/html/draft-fett-oauth-dpop
>> [2] - https://tools.ietf.org/html/rfc6749#section-7.1
>>
>> Best Regards,
>> Janak
>>
>> On Thu, Oct 31, 2019 at 9:42 AM Johann Nallathamby 
>> wrote:
>>
>>> Hi Darshana,
>>>
>>> On Sat, Sep 28, 2019 at 8:29 PM Darshana Gunawardana 
>>> wrote:
>>>
>>>> Hi Johann,
>>>>
>>>> On Sat, Sep 21, 2019 at 10:43 AM Johann Nallathamby 
>>>> wrote:
>>>>
>>>>> Hi Thanuja,
>>>>>
>>>>> Did we consider sending the access token itself as a secure, http-only
>>>>> cookie to the browser instead of binding it to a separate cookie? This 
>>>>> will
>>>>> also simplify the development on the client side, in case someone wants to
>>>>> build their own SPA.
>>>>>
>>>>
>>>> Here which domain you assumed that the cookie will be set to?
>>>>
>>>
>>> I meant to the IS server domain which is the domain where the APIs are
>>> hosted.
>>>
>>>
>>>>
>>>> Assuming it the client's domain, there are two limitations.
>>>>
>>>>1. Setting the token as a cookie is an additional task that client
>>>>had to do since OP (in this case IS) cannot set cookies for some 
>>>> external
>>>>client domain.
>>>>2. Having the token stored in http-only cookie block accessing it's
>>>>from client-side scripts, which is a main blocker for SPAs.
>>>>
>>>>
>>> Not client domain.
>>>
>>>
>>>>
>>>> Assuming it the server-side domain and assuming you want to
>>>> automatically handle authorization for the API based on the access token
>>>> that already present in the cookie, there are two concerns,
>>>>
>>>>1. This will open up CSRF vulnerability as any malicious client
>>>>running on the same browser can also access APIs successfully.
>>>>
>>>> Yes, your approach will prevent CSRF as well. +1.
>>>
>>>>
>>>>1. If the API gateway handling authorization in back-channel mode,
>>>>   1. The cookie has to set to the API gateway's domain
>>>>   2. API gateway has to do an additional non-standard way of
>>>>   handing this cookie and attach it to the authorization header.
>>>>
>>>> Yes, this is a possibility. But I wasn't proposing it in this case.
>>>
>>> Thanks for the clarification.
>>>
>>> Regards,
>>> Johann.
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>>>
>>>>> Regards,
>>>>> Johann.
>>>>>
>>>>> On Mon, Sep 2, 2019 at 12:26 PM Thanuja Jayasinghe 
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> With the introduction of new IAM portal applications, there is a
>>>>>> requirement to provide additional security measures to secure these SPAs.
>>>>>> We have already implemented the OAuth2 authorization code flow(public
>>>>>> client) with PKCE for these applications and with this feature, it will 
>>&

Re: [Architecture] [IAM][5.11.0] REST API For Identity Server Local Authenticators

[Thanuja Jayasinghe]

Hi Ruwan,


On Wed, Mar 18, 2020 at 9:36 AM Ruwan Abeykoon  wrote:

> Hi Sathya,
> If this is only used for authenticating SOAP calls, then we need not worry
> about managing it with REST.
> SOAP services is going to be deprecated in favor of REST API. It is all
> right to keep file based config and/or SOAP services to manage this.
>

The purpose of this API is not to provide authentication for SOAP calls,
rather it is designed to fulfill the following limitations with local
authenticators and related properties,
 - No API to return basic attributes of a local authenticator (ex:
whether the basic authenticator is enabled)
 - Can't create and manage multiple instances of a local authenticator
(ex: If we take Facebook federated authenticator, we can create multiple
instances with different configurations by creating multiple IdPs, but this
option is not available for local authenticators.)
  - No API to update server own configurations for authentication,
etc.(ex: session idle time for the tenant)

As the first step, we are creating this API to get the basic attributes of
local authenticators and it is essential for the new developer portal.


>
> Also, it is generally not a good idea to have API or Services to change
> "configs". Configs only to be done via file system.
> API is needed to change runtime data, in our case (SP, IdP, UserStore, etc)
>

As this manages local authenticators(in future) and related properties, it
will be run-time data. But yes, "configs" doesn't seem to be matched with
the purpose.


>
> Cheers,
> Ruwan A
>
>
> On Wed, Mar 18, 2020 at 9:20 AM Sathya Bandara  wrote:
>
>> Hi all,
>>
>> WSO2 Identity Server currently supports server local authenticator
>> related operations using SOAP APIs. I'm currently working on introducing a
>> REST API layer for this purpose in 5.11.0. In the initial phase only GET
>> operations will be supported in the API level since we do not allow to
>> add/update local authenticators from the backend OSGi service.
>>
>>- API for listing authenticators
>>
>>
>> * api/server/v1/configs/authenticators *
>>- API to retrieve authenticator by ID
>> * api/server/v1/configs/authenticators/{authenticator-id}*
>>
>> Please find the complete API definition in [1].
>>
>> Furthermore, since currently we do not have a REST API for managing
>> configurations available under the Resident IDP section e.g. idle session
>> timeout, going forward, we can introduce new APIs under
>> api/server/v1/configs context.
>>
>> Highly appreciate your valuable suggestions on this.
>>
>> [1] https://app.swaggerhub.com/apis/emswbandara/IAM_CONFIGS/0.1.0
>>
>> Thanks,
>> Sathya
>> --
>> Sathya Bandara
>> Senior Software Engineer
>> Blog: https://medium.com/@technospace
>> WSO2 Inc. http://wso2.com
>> Mobile: (+94) 715 360 421
>>
>> <+94%2071%20411%205032>
>>
>
>
> --
> Ruwan Abeykoon | Director/Architect | WSO2 Inc.
> (w) +947435800  | Email: ruw...@wso2.com
>
>
Thanks,
Thanuja
-- 
*Thanuja Lakmal*
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] WSO2 Identity Server 5.11.0 M6 Released!

[Thanuja Jayasinghe]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.11.0 M6!

Download

You can download WSO2 Identity Server 5.11.0 M6 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.11.0 M6

A list of all the new features and bug fixes shipped with this release can
be found in the following locations:


   - IS Runtime 
   - IAM Portals
   

Known
Issues

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

   - IS Runtime 
   - IAM Portals
   

Contribute
to WSO2 Identity Server
Mailing
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
   

Slack
Channels

Join us via our wso2is.slack.com

for
even better communication. You can talk to our developers directly
regarding any issues, concerns about the product. We encourage you to start
discussions or join any ongoing discussions with the team, via our slack
channels.

   - Discussions about developments: Dev Channel
   
   - New releases: Release Announcement Channel
   

Reporting
Issues

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

*Important: Please be advised that security issues must be reported
to secur...@wso2.com , not as GitHub issues, in order to
reach the proper audience. We strongly advise following the WSO2 Security
Vulnerability Reporting Guidelines

when
reporting the security 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 ~

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

Re: [Architecture] [Dev] [VOTE] Release WSO2 Identity Server 5.9.0 RC2

[Thanuja Jayasinghe]

Hi All,

I have tested the following API implementations and no blocking issues found.

- Session management API
- User Account Association API
- Export User profile
- Consent Management API

[+] Stable - go ahead and release

Thanks,
Thanuja


On Thu, Oct 3, 2019 at 6:16 PM Piraveena Paralogarajah
 wrote:
>
> Hi all.
>
> I have tested the following scenarios:
>
>
> Scope Management REST API
> XACML based scope validation for token issuing phase in the following OAuth 
> grant types
>
> Authorization code flow
> password grant
> client_credentials
> Implicit flow
>
> XACML based authorization
>
> No blocker issues found
> [+] Stable - go ahead and release
>
> Thanks,
> Piraveena
>
> Piraveena Paralogarajah
> Software Engineer | WSO2 Inc.
> (m) +94776099594 | (e) pirave...@wso2.com
>
>
>
> On Thu, Oct 3, 2019 at 3:45 PM Ashen Weerathunga  wrote:
>>
>> Hi All,
>>
>> I have tested the following scenarios and no blocking issues found.
>>
>> SSO with SAML
>> Federated authentication with Google
>> Federated authentication with Facebook
>> SSO with multi-option and multi-step authentication
>> Role-based Adaptive authentication
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> Ashen
>>
>>
>> On Thu, Oct 3, 2019 at 2:34 PM Shanika Wickramasinghe  
>> wrote:
>>>
>>> Hi All,
>>>
>>>
>>> I have tested the following features and no issues found
>>>
>>>
>>> Ubuntu 16.04 | MSSQL | Embedded Ldap Primary User Store | Super Tenant
>>>
>>>
>>> Manage roles with SCIM 2.0 Create Group, Delete Group, Filter Groups, 
>>> Search Groups, Update Group - PATCH, Update Group - PUT
>>>
>>> Manage users with SCIM 2.0 Create User Delete User by ID Filter Users 
>>> Search Users Update User - PATCH Update User - PUT
>>>
>>> Recover Username with dashboard
>>>
>>> Recover Password with dashboard
>>>
>>>
>>> Ubuntu 16.04 |  MSSQL | SecondaryUser Store | Super Tenant
>>>
>>>
>>> SP pagination with UI
>>>
>>> SP pagination with Admin Services
>>>
>>> Account Lock
>>>
>>> Recaptcha with Single Sign On
>>>
>>>
>>> Ubuntu 16.04 | H2/MSSQL | Embedded Ldap Primary User Store | Super Tenant
>>>
>>>
>>> Manage Workflows
>>>
>>>
>>> Ubuntu 16.04 | H2 | Embedded Ldap Primary User Store | Super Tenant
>>>
>>>
>>> Manage Workflows with QSG sample
>>>
>>> User self-registration via REST APIs
>>>
>>> User self-registration via user portal
>>>
>>> User manage his own user account, Update user profile
>>>
>>> OAuth 1.0 SP Creation/ Update
>>>
>>>
>>> +1 Go ahead and release.
>>>
>>>
>>> Thanks,
>>>
>>> Shanika
>>>
>>>
>>> On Thu, Oct 3, 2019 at 9:16 AM Achini Jayasena  wrote:

 Hi All,

 Tested and verified with performance test and long running test. Test 
 result match with the expectations.

 Performance test

 Summary:  Performance has been improved comparing to the product version 
 5.8

 Deployment

 OS: Ubuntu
 DB: Mysql
 Heap: 4G/2G
 CPU cores: 4
 Concurrent users: 50, 100, 150, 300, 500

 Scenarios:

 Authenticate_Super_Tenant_User
 OAuth_AuthCode_Redirect_WithConsent
 OAuth_Client_Credentials_Grant
 OAuth_Implicit_Redirect_WithConsent
 OAuth_Password_Grant
 OIDC_AuthCode_Redirect_WithConsent
 OIDC_AuthCode_Request_Path_Authenticator_WithConsent
 OIDC_Implicit_Redirect_WithConsent
 OIDC_Password_Grant
 SAML2_SSO_Redirect_Binding
 Challenge questions by super tenant users
 Refresh token refresh grant - Renewal false

 Long running test

 Summery: No issue reported.

 Deployment :

 IS node

 Instance type: c5.xlarge
 vCPU:4
 RAM: 8GB
 Heap: 2G allocated for IS

 RDS as the MySQL DB

 Mysql engine version : 5.7.22
 vCPU: 4
 Instance class : db.m4.xlarge
 RAM: 16 GB
 Storage: 100 GiB

 Executing test scenarios:

 Authenticate_Super_Tenant_User
 OAuth_AuthCode_Redirect_WithConsent
 OAuth_Password_Grant
 OIDC_AuthCode_Redirect_WithConsent
 OIDC_Implicit_Redirect_WithConsent
 OIDC_Password_Grant
 OIDC_AuthCode_Request_Path_Authenticator_WithConsent
 SAML2_SSO_Redirect_Binding

 Concurrency : 20
 TPS: 240 per minute

 No blocking issue reported. +1 for proceed. :)

 Thanks & Best Regards!
 Achini Jayasena
 Software Engineer - QA | WSO2

 Email: achi...@wso2.com
 Mobile: +94 713 882 897




 On Wed, Oct 2, 2019 at 10:31 PM Mathuriga Thavarajah  
 wrote:
>
> Hi All,
>
> Security Scanning reports (Static and Dynamic) were analyzed and 
> reviewed. Hence +1 from the Platform Security Team for proceeding with 
> the release.
>
> Thanks.
>
> Regards,
> Mathuriga.
>
> On Wed, Oct 2, 2019 at 10:08 PM Niluka Sripali Monnankulama 
>  wrote:
>>
>> Hi all,
>>
>>
>> Verified and validated below listed features are working as expected.
>>
>>
>> Te

Re: [Architecture] Binding access token to the browser for new IAM Portal Applications

[Thanuja Jayasinghe]

Update:

Table structure will be updated as follows,

IDN_OAUTH2_ACCESS_TOKEN (
TOKEN_ID VARCHAR (255),
ACCESS_TOKEN VARCHAR(2048),
REFRESH_TOKEN VARCHAR(2048),
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 NOT NULL DEFAULT CURRENT_TIMESTAMP,
REFRESH_TOKEN_TIME_CREATED TIMESTAMP NOT NULL DEFAULT
CURRENT_TIMESTAMP,
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),
ACCESS_TOKEN_HASH VARCHAR(512),
REFRESH_TOKEN_HASH VARCHAR(512),
IDP_ID INTEGER,
*TOKEN_BINDING_REF VARCHAR(32) DEFAULT 'NONE',*
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,IDP_ID, *TOKEN_BINDING_REF*)
)

// New Table
IDN_OAUTH2_ACCESS_TOKEN_BINDING (
TOKEN_ID VARCHAR (255),
TOKEN_BINDING_TYPE VARCHAR (32),
TOKEN_BINDING_REF VARCHAR (32),
TOKEN_BINDING_VALUE VARCHAR (1024),
TENANT_ID INTEGER DEFAULT -1,
PRIMARY KEY (TOKEN_ID),
FOREIGN KEY (TOKEN_ID) REFERENCES
IDN_OAUTH2_ACCESS_TOKEN(TOKEN_ID) ON DELETE CASCADE
)

Thanks,
Thanuja

On Thu, Sep 5, 2019 at 12:41 PM Thanuja Jayasinghe  wrote:

> Hi Hasintha,
>
> We are going to introduce the capability to bind the token to an external
> attribute as a part of this feature. So the updated schemas will be as
> follows,
>
> IDN_OAUTH2_ACCESS_TOKEN (
> TOKEN_ID VARCHAR (255),
> ACCESS_TOKEN VARCHAR(2048),
> REFRESH_TOKEN VARCHAR(2048),
> 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 NOT NULL DEFAULT CURRENT_TIMESTAMP,
> REFRESH_TOKEN_TIME_CREATED TIMESTAMP NOT NULL DEFAULT
> CURRENT_TIMESTAMP,
> 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),
> ACCESS_TOKEN_HASH VARCHAR(512),
> REFRESH_TOKEN_HASH VARCHAR(512),
> IDP_ID INTEGER,
> *TOKEN_BINDING_HASH VARCHAR(255) DEFAULT 'NONE',*
> 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,IDP_ID, *TOKEN_BIND_HASH*)
> )
>
> *// New Table*
> IDN_OAUTH2_ACCESS_TOKEN_BINDING (
> TOKEN_ID VARCHAR (255),
> TOKEN_BINDING VARCHAR (1024),
> TENANT_ID INTEGER DEFAULT -1,
> PRIMARY KEY (TOKEN_ID),
> FOREIGN KEY (TOKEN_ID) REFERENCES
> IDN_OAUTH2_ACCESS_TOKEN(TOKEN_ID) ON DELETE CASCADE
> )
>
> So with this implementation, each new binding will receive a new access
> token.
>
> In the user portal case, a new cookie will be created for each new browser
> instance and cookie value will be stored in
> the IDN_OAUTH2_ACCESS_TOKEN_BINDING table. Hash of this value will be added
> to IDN_OAUTH2_ACCESS_TOKEN table, creating a new access token for each new
> browser instance.
>
> Existing behavior also preserved when there are no token bindings provided.
>
> Thanks,
> Thanuja
>
> On Tue, Sep 3, 2019 at 12:19 PM Hasintha Indrajee 
> wrote:
>
>> Hi Thanuja,
>>
>> I have few questions on this.
>>
>> How are we going to bind the token to the cookie (Is this a new entry to
>> a table) ? Is this an existing cookie (may be commonAuth ID) or a  new
>> cookie ?. Furthermore, How are we going to handle the scenario where the
>> same user logs in from multiple browsers ? Are we going to have multiple
>> active tokens for same client, user with random scopes ? Or are we just
>> revoking th

Re: [Architecture] Binding access token to the browser for new IAM Portal Applications

[Thanuja Jayasinghe]

Hi Hasintha,

We are going to introduce the capability to bind the token to an external
attribute as a part of this feature. So the updated schemas will be as
follows,

IDN_OAUTH2_ACCESS_TOKEN (
TOKEN_ID VARCHAR (255),
ACCESS_TOKEN VARCHAR(2048),
REFRESH_TOKEN VARCHAR(2048),
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 NOT NULL DEFAULT CURRENT_TIMESTAMP,
REFRESH_TOKEN_TIME_CREATED TIMESTAMP NOT NULL DEFAULT
CURRENT_TIMESTAMP,
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),
ACCESS_TOKEN_HASH VARCHAR(512),
REFRESH_TOKEN_HASH VARCHAR(512),
IDP_ID INTEGER,
*TOKEN_BINDING_HASH VARCHAR(255) DEFAULT 'NONE',*
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,IDP_ID, *TOKEN_BIND_HASH*)
)

*// New Table*
IDN_OAUTH2_ACCESS_TOKEN_BINDING (
TOKEN_ID VARCHAR (255),
TOKEN_BINDING VARCHAR (1024),
TENANT_ID INTEGER DEFAULT -1,
PRIMARY KEY (TOKEN_ID),
FOREIGN KEY (TOKEN_ID) REFERENCES
IDN_OAUTH2_ACCESS_TOKEN(TOKEN_ID) ON DELETE CASCADE
)

So with this implementation, each new binding will receive a new access
token.

In the user portal case, a new cookie will be created for each new browser
instance and cookie value will be stored in
the IDN_OAUTH2_ACCESS_TOKEN_BINDING table. Hash of this value will be added
to IDN_OAUTH2_ACCESS_TOKEN table, creating a new access token for each new
browser instance.

Existing behavior also preserved when there are no token bindings provided.

Thanks,
Thanuja

On Tue, Sep 3, 2019 at 12:19 PM Hasintha Indrajee  wrote:

> Hi Thanuja,
>
> I have few questions on this.
>
> How are we going to bind the token to the cookie (Is this a new entry to a
> table) ? Is this an existing cookie (may be commonAuth ID) or a  new cookie
> ?. Furthermore, How are we going to handle the scenario where the same user
> logs in from multiple browsers ? Are we going to have multiple active
> tokens for same client, user with random scopes ? Or are we just revoking
> the old token if the same scopes are being used ?.
>
> Or else do we have the facility to have multiple active tokens for the
> same user, application with same scopes in latest IS versions ?
>
> On Mon, Sep 2, 2019 at 3:56 PM Thanuja Jayasinghe 
> wrote:
>
>> Hi All,
>>
>> With the introduction of new IAM portal applications, there is a
>> requirement to provide additional security measures to secure these SPAs.
>> We have already implemented the OAuth2 authorization code flow(public
>> client) with PKCE for these applications and with this feature, it will be
>> possible to bind the access token to the browser instance. So, an
>> additional security measure will be enforced as the combination of the
>> access token and browser token(cookie) validated while accessing the IS
>> APIs.
>> Support for configuring this option using OAuth2 application
>> configuration and browser token persistence will be added as well.
>>
>> Updated request/response flow is as follows,
>> [image: Blank Diagram (1).png]
>>
>> Thanks,
>> Thanuja
>>
>> --
>> *Thanuja Lakmal*
>> Technical Lead
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891
>>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453
>
>

-- 
*Thanuja Lakmal*
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] Binding access token to the browser for new IAM Portal Applications

[Thanuja Jayasinghe]

Hi All,

With the introduction of new IAM portal applications, there is a
requirement to provide additional security measures to secure these SPAs.
We have already implemented the OAuth2 authorization code flow(public
client) with PKCE for these applications and with this feature, it will be
possible to bind the access token to the browser instance. So, an
additional security measure will be enforced as the combination of the
access token and browser token(cookie) validated while accessing the IS
APIs.
Support for configuring this option using OAuth2 application configuration
and browser token persistence will be added as well.

Updated request/response flow is as follows,
[image: Blank Diagram (1).png]

Thanks,
Thanuja

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

Re: [Architecture] [IS- 5.10.0] [Role-Permission] Implementation strategy

[Thanuja Jayasinghe]

+1 for approach 2.

What will be a sample response for GET "
https://localhost:9443/scim2/Groups/c39232b1-4856-439b-89be-aae3fce5617d/permissions";
?

Thanks,
Thanuja

On Thu, Aug 29, 2019 at 11:41 AM Dinali Dabarera  wrote:

>
> Hi Denuwanthi,
>
> On Thu, Aug 29, 2019 at 11:37 AM Denuwanthi De Silva 
> wrote:
>
>> +1 for Approach 2.
>> It provides a sense of modularity/decoupling and helps the api user to
>> easily navigate api calls  using the provided link.
>> Will this effort also cover associating permissions to roles?
>>
>
> I believe what you mean here is add permission to roles.
>
> Yes, for that we provide the POST form of this API. We do support PATCH,
> PUT and DELETE too.
>
> *"https://localhost:9443/scim2/Groups/c39232b1-4856-439b-89be-aae3fce5617d/permissions";
> *
>
>
>
>> Thanks,
>>
>> On Thu, Aug 29, 2019 at 10:52 AM Dinali Dabarera  wrote:
>>
>>> Correction:
>>>
>>> *Approach 2:*
>>> Ex:
>>>
>>> {
>>>   "totalResults": 1,
>>>   "startIndex": 1,
>>>   "itemsPerPage": 1,
>>>   "schemas": [
>>> "urn:ietf:params:scim:api:messages:2.0:ListResponse"
>>>   ],
>>>   "Resources": [
>>> {
>>>   "displayName": "PRIMARY/admin",
>>>   "meta": {
>>> "created": "2019-07-26T19:33:54",
>>> "location": 
>>> "https://localhost:9443/scim2/Groups/c39232b1-4856-439b-89be-aae3fce5617d";,
>>> "lastModified": "2019-07-26T19:33:54"
>>>   },
>>>   "members": [
>>> {
>>>   "display": "admin",
>>>   "value": "409ca90b-2ba6-4474-9a45-2cf7376e6e43"
>>> }
>>>   ],
>>>
>>>
>>> *  "permissions" : {  "location":*
>>>
>>> *"https://localhost:9443/scim2/Groups/c39232b1-4856-439b-89be-aae3fce5617d/permissions";
>>> *
>>> },
>>>  "id": "c39232b1-4856-439b-89be-aae3fce5617d" } ] }
>>>
>>>
>>> On Thu, Aug 29, 2019 at 10:38 AM Dinali Dabarera 
>>> wrote:
>>>
 Hi all,

 We currently have the UserAdmin Service method to return all the
 permissions in the permission tree as a node list object. There is also a
 method to return permissions associated with a role.

 When we try to implement a rest API for this we came up with below two
 approaches:

 *Approach 1:*

- Return the only the visible permission list in the SCIM group
object itself, similar way as members listed. The expected outcome is 
 shown
below.

 Ex:

 {
   "totalResults": 3,
   "startIndex": 1,
   "itemsPerPage": 3,
   "schemas": [
 "urn:ietf:params:scim:api:messages:2.0:ListResponse"
   ],
   "Resources": [
 {
   "displayName": "PRIMARY/admin",
   "meta": {
 "created": "2019-07-26T19:33:54",
 "location": 
 "https://localhost:9443/scim2/Groups/c39232b1-4856-439b-89be-aae3fce5617d";,
 "lastModified": "2019-07-26T19:33:54"
   },
   "members": [
 {
   "display": "admin",
   "value": "409ca90b-2ba6-4474-9a45-2cf7376e6e43"
 }
   ],

   "permissions" : [
 {

 "displayName" : "Configure Data Sources",

 "resourcePath" : "/permission/admin/configure/datasources"
  },
  {

 "displayName" : "Password Management",

 "resourcePath" : 
 "/permission/admin/configure/security/usermgt/passwords"

 }
 ]
  "id": "c39232b1-4856-439b-89be-aae3fce5617d" } ] }



 *Approach 2: *


- If we return the permission list in the same group object, it
will become really large and will have a lot of backend changes as well.
- Hence, we thought of returning only the link to the permission
list in the group object and implement another few APIs to manage
permissions, basically the CRUD operations.

 Ex:

 {
   "totalResults": 3,
   "startIndex": 1,
   "itemsPerPage": 3,
   "schemas": [
 "urn:ietf:params:scim:api:messages:2.0:ListResponse"
   ],
   "Resources": [
 {
   "displayName": "PRIMARY/admin",
   "meta": {
 "created": "2019-07-26T19:33:54",
 "location": 
 "https://localhost:9443/scim2/Groups/c39232b1-4856-439b-89be-aae3fce5617d";,
 "lastModified": "2019-07-26T19:33:54"
   },
   "members": [
 {
   "display": "admin",
   "value": "409ca90b-2ba6-4474-9a45-2cf7376e6e43"
 }
   ],

 * "permissions" :
 ["https://localhost:9443/scim2/Groups/c39232b1-4856-439b-89be-aae3fce5617d/permissions
 

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

[Thanuja Jayasinghe]

Hi All,

Tested following scenarios,

- Local user account association
- OAuth2 grat types (code, implicit, password, client credential)
- SAML2 SSO & SLO

[+] Stable - go ahead and release.

Thanks,
Thanuja

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

[Architecture] WSO2 Identity Server 5.8.0-alpha2 Released!

[Thanuja Jayasinghe]

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

You can download WSO2 Identity Server 5.8.0 alpha2 from here

.

You can download WSO2 Identity Server Analytics 5.8.0 alpha2 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 alpha2

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 ~

-- 
*Thanuja Lakmal*
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] WSO2 Identity Server 5.8.0-M25 Released!

[Thanuja Jayasinghe]

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

You can download WSO2 Identity Server 5.8.0 M25 from here

.

You can download WSO2 Identity Server Analytics 5.8.0 M25 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 M25

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 ~

-- 
*Thanuja Lakmal*
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] WSO2 Identity Server 5.8.0-M24 Released!

[Thanuja Jayasinghe]

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

You can download WSO2 Identity Server 5.8.0 M24 from here

.

You can download WSO2 Identity Server Analytics 5.8.0 M24 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 M24

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 ~

-- 
*Thanuja Lakmal*
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] WSO2 Identity Server 5.8.0-M3 Released!

[Thanuja Jayasinghe]

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

You can download WSO2 Identity Server 5.8.0 M3 from here

.

You can download WSO2 Identity Server Analytics 5.8.0 M3 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 M3

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 ~

-- 
*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] WSO2 Identity Server 5.8.0-M2 Released!

[Thanuja Jayasinghe]

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

You can download WSO2 Identity Server 5.8.0 M2 from here

.

You can download WSO2 Identity Server Analytics 5.8.0 M2 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 M2

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 ~

-- 
*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] WSO2 Identity Server 5.8.0-M1 Released!

[Thanuja Jayasinghe]

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

You can download WSO2 Identity Server 5.8.0 M1 from here

.

You can download WSO2 Identity Server Analytics 5.8.0 M1 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 M1

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 ~
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Thanuja Jayasinghe]

Hi All,

I have tested the following and no issues were found.

   - Overall login attempts dashboard
   - Suspicious login attempts dashboard

[+] Stable - go ahead and release

Thanks,
Thanuja

On Tue, Sep 18, 2018 at 5:07 PM Chamath Samarawickrama 
wrote:

> Hi,
>
> I have tested the following on WSO2 Identity Server Analytics 5.7.0 RC3.
>
>- Overall login attempts dashboard
>- Suspicious login attempts dashboard
>- Login sessions dashboard
>- Configuring risk-based Adaptive Authentication
>
> No blocking issues were found.
>
> *[+] Stable - go ahead and release*
>
> Thanks,
> Chamath
>
> On Tue, Sep 18, 2018 at 3:42 PM Nuwandi Wickramasinghe 
> wrote:
>
>> Hi All,
>>
>>
>> We are pleased to announce the third release candidate of WSO2 Identity
>> Server Analytics 5.7.0.
>>
>>
>> This release fixes the following issues,
>>
>>
>>
>>- 5.7.0-RC3 Fixes
>>
>>- 5.7.0-RC2 Fixes
>>
>>- 5.7.0-RC1 Fixes
>>
>>
>>
>>
>> Source and distribution,
>>
>>
>>- https://github.com/wso2/analytics-is/releases/v5.7.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 -
>>
>> --
>>
>> Best Regards,
>>
>> Nuwandi Wickramasinghe
>>
>> Senior Software Engineer
>>
>> WSO2 Inc.
>>
>> Web : http://wso2.com
>>
>> Mobile : 0719214873
>>
>
>
> --
> *C**h**amath Samarawickrama*
> Intern | WSO2, Inc.
> Mobile : +94772598944
> Twitter   LinkedIn
>   GitHub
> 
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


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

Re: [Architecture] [Dev][VOTE] Release of WSO2 Identity Server Analytics 5.7.0 RC2

[Thanuja Jayasinghe]

Hi All,

I have tested the following and no issues were found.

   - Overall login attempts dashboard
   - Suspicious login attempts dashboard

[+] Stable - go ahead and release

Thanks,
Thanuja

On Sat, Sep 15, 2018 at 12:45 PM Dilin Dampahalage  wrote:

> Hi all,
>
>
> We are pleased to announce the second release candidate of WSO2 Identity
> Server Analytics 5.7.0.
>
>
> This release fixes the following issues,
>
>-
>
>5.7.0-RC2 fixes
>
>-
>
>5.7.0-RC1 fixes
>
> 
>
>
> Source and distribution,
>
>
>Runtime - https://github.com/wso2/analytics-is/releases/v5.7.0-rc2
>
>
>
> 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 -
>
> --
>
> *Dilin Dampahalage*
> Software Engineer | WSO2
>
> Email : di...@wso2.com
> Mobile : +94 771 462939
> web : http://wso2.com
>
> 
>


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

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

[Thanuja Jayasinghe]

Hi All,

Thanks for testing WSO2 Identity Server 5.7.0-RC3.

Since this vote passed with 28 +1s and 0 -1s, we’re hereby closing this
vote and proceeding with the Identity Server 5.7.0 GA release.

Thanks,
Thanuja

On Mon, Sep 17, 2018 at 10:01 AM Dilin Dampahalage  wrote:

> Hi all,
>
> I have tested IS 5.7.0-RC3 with IS Analytics 5.7.0 Beta and it works fine.
>
> No issues were found.
>
>  [+] Stable - go ahead and release
>
> Thanks,
> Dilin
>
>
> On Sun, Sep 16, 2018 at 9:09 AM Abilashini Thiyagarajah <
> abilash...@wso2.com> wrote:
>
>> Hi all,
>>
>> I have tested the following scenarios,
>>
>> - Role-based adaptive authentication
>> - User-age-based adaptive authentication
>> - Tenant-based adaptive authentication
>> - New-device-based adaptive authentication
>> - ACR-based adaptive authentication
>> - Self-registration and account confirmation with & without consent
>> purposes
>> - Account recovery
>>
>> - username
>> - password - using mail notification and challenge question
>>
>> - Creating users using the ask password option
>>
>> No issues were found.
>>
>>  [+] Stable - go ahead and release
>>
>> Thanks,
>> Abilashini
>>
>>
>> On Sat, Sep 15, 2018 at 3:27 PM Sarubi Thillainathan 
>> wrote:
>>
>>> Hi All,
>>>
>>> I have tested the following on both LDAP and JDBC user stores and no
>>> issues were found.
>>>
>>> * Multi-attribute filter search with and without pagination
>>> * All the available SCIM2 endpoints which are given in doc [1]
>>>
>>> [+] Stable - go ahead and release.
>>>
>>> [1] https://docs.wso2.com/display/IS570/apidocs/SCIM2-endpoints/
>>>
>>> On Sat, Sep 15, 2018 at 2:24 AM Mathuriga Thavarajah 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I have tested the following and no issues were found.
>>>>
>>>> * Settip up MySQL 5.7
>>>> * Configuring a Read-write Active Directory User Store as a
>>>> secondary user store
>>>> * Configuring Multi-factor Authentication (Basic and Google as
>>>> a federated authenticator)
>>>> * Configuring LDAP Active Directory as a primary store in WSO2
>>>> Identity Server 5.7.0 RC3 on windows instance.
>>>>
>>>> [+] Stable - go ahead and release.
>>>>
>>>> Regards,
>>>> Mathuriga.
>>>>
>>>>
>>>> On Fri, Sep 14, 2018 at 5:23 PM Thanuja Jayasinghe 
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I have tested the following and no issues were found.
>>>>>
>>>>>- User account association
>>>>>- Workflow management
>>>>>- Adaptive authentication
>>>>>- Role-based
>>>>>   - User age based
>>>>>
>>>>> [+] Stable - go ahead and release
>>>>>
>>>>> Thanks,
>>>>> Thanuja
>>>>> ___
>>>>> Dev mailing list
>>>>> d...@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Mathuriga Thavarajah*
>>>> Software Engineer
>>>> WSO2 Inc. - http ://wso2.com
>>>>
>>>> Email : mathur...@wso2.com
>>>> Mobile  : +94778191300
>>>>
>>>>
>>>>
>>>> *[image: http://wso2.com/signature] <http://wso2.com/signature>*
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> *Sarubi Thillainathan *
>>> *Software Engineer - WSO2 Inc.*
>>>
>>> *Mobile : +94 (0) 76 68 49 101*
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Abilashini Thiyagarajah
>> Software Engineer
>> WSO2, Inc.
>> Mobile: +94 778983001
>> <http://wso2.com/signature>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
>
> *Dilin Dampahalage*
> Software Engineer | WSO2
>
> Email : di...@wso2.com
> Mobile : +94 771 462939
> web : http://wso2.com
>
> <http://wso2.com/signature>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


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

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

[Thanuja Jayasinghe]

Hi All,

I have tested the following and no issues were found.

   - User account association
   - Workflow management
   - Adaptive authentication
   - Role-based
  - User age based

[+] Stable - go ahead and release

Thanks,
Thanuja
___
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.7.0 RC1

[Thanuja Jayasinghe]

Hi All,

We are closing the vote as we found an issue while working with the
PostgreSQL database. We will fix the issue and release another release
candidate as soon as possible.

Thanks,
Thanuja

On Sat, Sep 8, 2018 at 6:34 AM Thanuja Jayasinghe  wrote:

> Hi All,
>
> We are pleased to announce the first release candidate(RC) of WSO2
> Identity Server 5.7.0.
>
> This release fixes the following issues,
>
>- 5.7.0-RC Fixes
><https://github.com/wso2/product-is/milestone/52?closed=1>
>- 5.7.0-Beta2 Fixes
><https://github.com/wso2/product-is/milestone/57?closed=1>
>- 5.7.0-Beta Fixes
><https://github.com/wso2/product-is/milestone/54?closed=1>
>- 5.7.0-Alpha3 Fixes
><https://github.com/wso2/product-is/milestone/53?closed=1>
>- 5.7.0-Alpha2 Fixes
><https://github.com/wso2/product-is/milestone/51?closed=1>
>- 5.7.0-Alpha Fixes
><https://github.com/wso2/product-is/milestone/50?closed=1>
>- 5.7.0-M5 Fixes
><https://github.com/wso2/product-is/milestone/49?closed=1>
>- 5.7.0-M4 Fixes
><https://github.com/wso2/product-is/milestone/48?closed=1>
>- 5.7.0-M3 Fixes
><https://github.com/wso2/product-is/milestone/47?closed=1>
>- 5.7.0-M2 Fixes
><https://github.com/wso2/product-is/milestone/46?closed=1>
>- 5.7.0-M1 Fixes
><https://github.com/wso2/product-is/milestone/45?closed=1>
>
> Source and distribution,
>  - https://github.com/wso2/product-is/releases/tag/v5.7.0-rc1
>
> Please download, test the product and vote.
>
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> ~ The WSO2 Identity and Access Management Team ~
>
>

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

Re: [Architecture] [Dev][VOTE] Release of WSO2 Identity Server Analytics 5.7.0 RC1

[Thanuja Jayasinghe]

Hi All,

We are closing the vote as we found an issue while configuring it for
risk-based adaptive authentication. We will fix the issue and release
another release candidate as soon as possible.

Thanks,
Thanuja

On Sat, Sep 8, 2018 at 11:17 PM Thanuja Jayasinghe  wrote:

> Hi All,
>
> We are pleased to announce the first release candidate(RC) of WSO2
> Identity Server Analytics 5.7.0.
>
> This release fixes the following issues,
>
>- 5.7.0-RC Fixes
><https://github.com/wso2/analytics-is/milestone/2?closed=1>
>
>
> Source and distribution,
>  - https://github.com/wso2/analytics-is/releases/tag/v5.7.0-rc1
>
> Please download, test the product and vote.
>
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> ~ The WSO2 Identity and Access Management Team ~
>
>

-- 
*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] [Dev][VOTE] Release of WSO2 Identity Server Analytics 5.7.0 RC1

[Thanuja Jayasinghe]

Hi All,

We are pleased to announce the first release candidate(RC) of WSO2 Identity
Server Analytics 5.7.0.

This release fixes the following issues,

   - 5.7.0-RC Fixes
   


Source and distribution,
 - https://github.com/wso2/analytics-is/releases/tag/v5.7.0-rc1

Please download, test the product and vote.

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

Thanks,
~ The WSO2 Identity and Access Management Team ~
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev][VOTE] Release of WSO2 Identity Server 5.7.0 RC1

[Thanuja Jayasinghe]

Hi All,

We are pleased to announce the first release candidate(RC) of WSO2 Identity
Server 5.7.0.

This release fixes the following issues,

   - 5.7.0-RC Fixes
   
   - 5.7.0-Beta2 Fixes
   
   - 5.7.0-Beta Fixes
   
   - 5.7.0-Alpha3 Fixes
   
   - 5.7.0-Alpha2 Fixes
   
   - 5.7.0-Alpha Fixes
   
   - 5.7.0-M5 Fixes
   
   - 5.7.0-M4 Fixes
   
   - 5.7.0-M3 Fixes
   
   - 5.7.0-M2 Fixes
   
   - 5.7.0-M1 Fixes
   

Source and distribution,
 - https://github.com/wso2/product-is/releases/tag/v5.7.0-rc1

Please download, test the product and vote.

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

Thanks,
~ The WSO2 Identity and Access Management Team ~
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.7.0-beta2 Released!

[Thanuja Jayasinghe]

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

You can download WSO2 Identity Server 5.7.0 beta2 from here

.

You can download WSO2 Identity Server Analytics 5.7.0 beta2 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.7.0 Beta2

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 ~
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM] Service Provider Template Support

[Thanuja Jayasinghe]

Hi,
On Wed, Jul 18, 2018 at 6:47 AM Indunil Upeksha Rathnayake 
wrote:

> Hi,
>
> In WSO2 Identity Server, we are planning to include Service Provider
> Template Support which will be exposed a way to create service providers
> with pre-configured and reusable templates. There will be several business
> use cases for this and following is an example.
>
>- In API subscription of APIM, an OAuth service provider will be
>created, but with only the SP basic information and OAuth inbound
>configurations.
>
>
>- If we need to include claim configurations, authentication
>configurations etc, those should be added manually from management console.
>
>
>- If there are multiple service providers with same configurations, it
>will be a huge burden (ex: every SP in a tenant should be authenticated
>with TOTP as the second step).
>
>
>- With the use of DCR endpoint and SP template support, a template
>with the necessary pre-configured values can be used when creating the SP.
>
>
>
> Please find the following approach which will be taken to achieve this
> requirement.
>
> Service providers can be added in IS, using following ways and we will be
> including the template support for those as follows.
>
>1. From management console
>2. Using admin services
>3. Using DCR endpoint
>
> *SP templates from Management Console*
>
> SP templates can be added from the management console where templates will
> be with a set of properties of SP, which can be pre-configured (ex: SP name
> cannot be pre-configured which will be unique for each SP. So eventhough
> it's configured in the template, when loading the template it should not be
> considered). Template name and a description has to be provided when
> creating a template.
>
> A default SP template for a tenant can be added from management console
> which will be named as "default".
>

Would it be a good idea to create a default service provider template for a
tenant during the tenant creation using a template file(in the conf folder)?


>
> *Store SP Templates in Database*
>
> The configured SP templates will be stored in database table, which is
> with following database schema.
>
>
>
>
Template name needs to be unique. So we need to have a unique constraint
for tenant_id and name combination.


> *Template selection in SP creation*
>
> User can select a specific SP template when creating a SP. In SP creation,
> SP configurations will be populated with the pre-configured details in the
> selected template and empty fields for other configurations.
>

What are the exact service provider configurations which will be supported
by the template?


>
> In the authentication steps, if the specified IDP in the template is not
> exists, pop up an error message in UI mentioning that this is an invalid
> template and send appropriate error message in DCR.
>

Is there a way to recover the template if it is invalid, maybe removing
invalid elements from it?


>
> *Template selection in DCR endpoint*
>
> DCR endpoint will be invoked with template name as a custom client
> metadata parameter(i.e. "sp_template"). Based on that the corresponding
> template will be selected for SP creation.
>
> If template with that name is not exists, will be using the tenant default
> template and if the tenant default template is not exists, will be using
> the global authentication sequence configuration in
> application-authentication.xml.
>

Instead of using the default template, don't we need to send an error
response back? As the "sp_template" input parameter is invalid?


>
>
> Highly appreciate your thoughts and suggestions over the suggested
> approach.
>
>
> Thanks and Regards
> --
> Indunil Upeksha Rathnayake
> Senior Software Engineer | WSO2 Inc
> Emailindu...@wso2.com
> Mobile   0772182255
>

Thanks,
Thanuja
-- 
*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

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

[Thanuja Jayasinghe]

Hi All,

Tested user account association scenarios. No blocking issues found.

[+] Stable - Go ahead and release

Thanks,
Thanuja

On Tue, Jun 19, 2018 at 3:48 PM Isuri Anuradha  wrote:

> Hi all,
>
> I've tested following scenarios on the IS 5.6.0-RC3 pack.
>
>- SAML to SAML federation flow.
>- Publish and Update XACML policies.
>- OAuth token revocation.
>
> No blocking issues found.
>
> [+] Stable
>
> Thanks
> Isuri.
>
> On Tue, Jun 19, 2018 at 3:34 PM, Omindu Rathnaweera 
> wrote:
>
>> Hi All,
>>
>> Tested SCIM 2.0 basic operations. No blocking issues found
>>
>> [+] Stable - Go ahead and release
>>
>> Regards,
>> Omindu.
>>
>>
>>
>>
>>
>> On Tue, Jun 19, 2018 at 3:14 PM Nipuni Bhagya  wrote:
>>
>>> Hi all,
>>>
>>> I've tested following scenarios on the IS 5.6.0-RC3 pack.
>>>
>>>- Configuring Single-Sign-On with SAML2
>>>- Configuring Single-Sign-On with OIDC
>>>- Configuring Multi-Factor Authentication
>>>- Configuring Twitter as a Federated Authenticator
>>>- Setting up Self-Signup
>>>- Creating a workflow
>>>- Tested Consent management API (Add/Retrieve purposes, Add/revoke
>>>consents.)
>>>
>>> No blocking issues found.
>>>
>>> [+] Stable
>>>
>>> Thanks,
>>>
>>>
>>> On Tue, Jun 19, 2018 at 2:38 AM Pulasthi Mahawithana 
>>> wrote:
>>>
 Hi,

 Tested SSO with Multi step/multi option authentication, Google
 and Twitter authenticators

 No blocking issues found.

 [+] Stable - Go ahead and release


 On Tue, Jun 19, 2018 at 2:59 PM Hasanthi Purnima Dissanayake <
 hasan...@wso2.com> wrote:

> Hi,
>
> Tested below scenarios on IS 5.6.0-RC3 pack,
>
> - Register a service provider
> - Obtain an access token using JWT grant type
> - Invoke user info endpoint using the token.
>
> No blocking issues found.
>
> [+] Stable - Go ahead and release
>
> Thanks,
> Hasanthi
>
> On Tue, Jun 19, 2018 at 2:44 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 rel

Re: [Architecture] [Dev] [VOTE] Release WSO2 Identity Server 5.5.0 RC2

[Thanuja Jayasinghe]

Hi,

Tested following scenarios on RC2 pack.

   - User account association(Local/Federated)
   - SAML2 IdP creation with metadata file
   - Workflow management

[+] Stable - Go ahead and release.

Thanks,
Thanuja


On Thu, Mar 15, 2018 at 2:52 PM, Prakhash Sivakumar 
wrote:

> Hi all,
>
> I have reviewed the following reports prepared by the product team.
>
> 1. Dynamic analysis report
> 2. Static analysis report.
>
> no issues with the analysis reports.
>
> +1, Go ahead and release.
>
> Thanks,
> Prakhash
>
>
>
>
> On Thu, Mar 15, 2018 at 2:45 PM, Jayanga Kaushalya 
> wrote:
>
>> Hi all,
>>
>> I have tested the following,
>>
>> 1. Forget-me tool in IS RC2 pack.
>> 2. Forget-me tool in IS Analytics RC2 pack.
>>
>> No blocking issues found.
>>
>> [+] Go ahead and release.
>>
>> Thanks!
>>
>> *Jayanga Kaushalya*
>> Senior Software Engineer
>> Mobile: +94777860160 <+94%2077%20786%200160>
>> WSO2 Inc. | http://wso2.com
>> lean.enterprise.middleware
>>
>>
>>
>> On Thu, Mar 15, 2018 at 1:26 PM, Ishara Karunarathna 
>> wrote:
>>
>>> HI,
>>>
>>> Tested the consent mgt feature with SAML SSO. and basic user mgt
>>> features.
>>> No blocking issues found.
>>>
>>> [+] Stable - Go ahead and release
>>>
>>> -Ishara
>>>
>>> On Thu, Mar 15, 2018 at 1:08 PM, Pulasthi Mahawithana <
>>> pulast...@wso2.com> wrote:
>>>
 Tested below scenarios and no blocking issues found.,

- Adding multi-Step workflow definitions
- Adding workflow associations and Multi step approval for user add
operation
- Federation with twitter
- Login analytics
- Session Analytics

 No blocking issues found.

 [+] Stable - Go ahead and release

 On Thu, Mar 15, 2018 at 12:33 PM, Hasintha Indrajee 
 wrote:

> Tested below scenarios with MySQL database
>
> Authentication data publishing.
> Custom OAuth client authenticators (Private key JWT client
> authenticator.)
>
> Self registration with consents (for super and non super tenants)
> SSO with missing mandatory claims and consents for SaaS apps. (SAML,
> with and without mandatory claims)
> Updating and revoking consents through dashboard for super tenant and
> non super tenant users.
> Consent erasure while apps (for SaaS scenarios) are deleted and users
> are deleted.
>
> No blocking issues found and +1 to proceed with release.
>
>
> On Thu, Mar 15, 2018 at 5:19 AM, Darshana Gunawardana <
> darsh...@wso2.com> wrote:
>
>> Hi all,
>>
>> We are pleased to announce the second release candidate of WSO2
>> Identity Server 5.5.0.
>>
>> This release fixes the following issues,
>>
>>-
>>- 5.5.0-RC2 fixes
>>
>> 
>>- 5.5.0-RC1 fixes
>>
>> 
>>- 5.5.0-Beta fixes
>>
>> 
>>- 5.5.0-Alpha3 fixes
>>
>> 
>>- 5.5.0-Alpha2 fixes
>>
>> 
>>- 5.5.0-Alpha fixes
>>
>> 
>>- 5.5.0-M4 fixes
>>
>> 
>>- 5.5.0-M3 fixes
>>
>> 
>>- 5.5.0-M2 fixes
>>
>> 
>>- 5.5.0-M1 fixes
>>
>> 
>>
>>
>> Source and distribution
>>
>> Runtime - https://github.com/wso2/product-is/releases/v5.5.0-rc2
>> Analytics - https://github.com/wso2/anal
>> ytics-is/releases/v5.5.0-rc2
>>
>>
>> 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 -
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <071%20856%206859>*Lean . Enterprise .
>> Middleware
>>
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org

Re: [Architecture] Federated IdP Initiated Logout

[Thanuja Jayasinghe]

Hi,

On Mon, Jan 15, 2018 at 1:32 PM, Dimuthu Leelarathne 
wrote:

> Hi All,
>
> Please consider the below scenario.
>
>
> ​
>
>
> When the Federated IdP sends the logout request we have to logout the user
> from the WSO2IS.  The proposed POC is as follows.
>
> - 1 & 4 are OAuth flows
> - 2 & 3 are SAML flows
>
> Participants of the discussion: Malithi, Thanuja and Dimuthu
>
> For the POC we will do the following.
>
> a) - At number 4 in the diagram, i.e. at the conclusion flow, we implement
> a listener that would record the SAML session Index vs. session Id in an
> appropriate data structure (for the POC it is a map). This handler will be
> in the out-boud SAML component.
>

We need to implement AuthenticationDataPublisher inside the
saml-sso outbound authenticator to handle this. Code references can be
found in  [1], [2] and [3].


>
> b) - At number 5 in the diagram, i.e. when the logout request is received,
> we  wrap the request and response and send over to our common-auth
> servelet. Here before invoking the common-auth servelet, we will retrieve
> session Id from the map (using the SAML Session Index) and set it in the
> wrapper object.
>

Request which forwards to the commonauth endpoint will have a format
similar to following,
*/commonauth?commonAuthLogout=true&type={type}&commonAuthCallerPath={some-url}&relyingParty={sp-name}*
NOTE: Need to verify whether relyingParty parameter is required or not.

After logout from the framework, the saml-sso outbound component will
verify the response and will build a valid SAML2 logout response and send
back to the federated IdP.

Sample wrapper implementation can be found in [1] and [2].


>
> @Thanuja and Malithi: Please add anything that I have missed. And also
> appreciate code snippets for above (a) and (b).
>
> After the POC implementation, we will have another review.
>
> thank you,
> Dimuthu
>
> --
> Dimuthu Leelarathne
> Director, Solutions Architecture
>
> WSO2, Inc. (http://wso2.com)
> email: dimut...@wso2.com
> Mobile: +94773661935 <+94%2077%20366%201935>
> Blog: http://muthulee.blogspot.com
>
> Lean . Enterprise . Middleware
>

[1] - https://github.com/wso2/carbon-identity-framework/
blob/5.11.x/components/authentication-framework/org.wso2.carbon.identity.
application.authentication.framework/src/main/java/org/wso2/carbon/identity/
application/authentication/framework/util/FrameworkUtils.java#L1258

[2]
-
https://github.com/wso2/carbon-identity-framework/blob/5.11.x/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/AuthenticationDataPublisher.java

[3] -
https://github.com/wso2-extensions/identity-governance/blob/master/components/org.wso2.carbon.identity.captcha/src/main/java/org/wso2/carbon/identity/captcha/validator/FailLoginAttemptValidator.java

[4] -
https://github.com/wso2/carbon-identity-framework/blob/5.11.x/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/model/CommonAuthRequestWrapper.java

[5] -
https://github.com/wso2/carbon-identity-framework/blob/5.11.x/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/model/CommonAuthResponseWrapper.java


Thanks,
Thanuja
-- 
*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

Re: [Architecture] Does WSO2 Identity Server support IDP initiated logout from federated IDP?

[Thanuja Jayasinghe]

Hi Roman,

On Thu, Nov 16, 2017 at 5:56 PM, Roman CHRENKO 
wrote:

> Hello.
>
> We are using WSO2 Identity Server 5.3.0.
>
> I configured trust between WSO2 IDP (symbolic name "IDP1") and the Service
> Provider (Shibboleth, symbolic name "SP1").
>
> Then I configured second trust between WSO2 acting as a service provider
> ("SP2") and federated IDP (symbolic name "IDP2", some public/gov service).
>
> I followed instructions at https://docs.wso2.com/display/
> IS530/Configuring+Shibboleth+IdP+as+a+Trusted+Identity+Provider.
>
> SP1 protects some resources, access to them is granted only when users are
> authenticated to IDP2. Everything is based on SAML protocol.
>
> Login works fine - login requests are redirected from WSO2(=IDP1) to IDP2.
>
> IDP1 initiated logout works fine too (user is sending GET to
> https://idp1.mydomain.com/samlsso?slo=true&spEntityID=
> https://sp1.mydomain.com/shibboleth ).
>
> But IDP2 initiated logout fails with message (in a browser): "Attention:
> Something went wrong during the authentication process. Please try signing
> in again."
>
> It generates record to the WSO2 log: "{...DefaultRequestCoordinator}
> Context does not exist. Probably due to invalidated cache".
>
> During the IDP2 initiated logout correct LogoutRequest is sent from IDP2
> to WSO2 (to https://amsrv.mydomain.com:9443/commonauth).
>
> (Our WSO2 is only one of many Service Providers which trust IDP2. IDP2 is
> central identity provider for government institutions.
>
> IDP2 supports SSO, so logout can be initiated from many independent
> applications (Service providers). But from out point of view it is
> initiated from IDP2.)
>
> Does WSO2 support such scenario (IDP2 initiated logout)?
>

No. This is not supported.


> If not, when will it be supported?
>

Created JIRA [1] to track this feature.


> If yes, where is it documented?
>
>
>
> Best regards,
>
> Roman
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
As a workaround can you try sending modified IdP initiated logout request
to the /samlsso endpoint from the IDP2?
- In this case, WSO2 IS(IDP1) will send a logout request to IDP2 and IDP2
need to handle it and send back a successful response.
- In the SP1 configuration of WSO2 IS(IDP1), you need to configure a
landing URL in IDP2 as a "Return to URL" after the single logout.
  Ex:
https://idp1.mydomain.com/samlsso?slo=true&spEntityID=https://sp1.mydomain.com/shibboleth&returnTo=https://idp2/logout-success
(IDP2 can't send an SP initiated logout request since the session index
will not be available at /samlsso endpoint (inbound) side)

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

Thanks,
Thanuja
-- 
*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

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

[Thanuja Jayasinghe]

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.

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

Re: [Architecture] Force Delete Identity Providers

[Thanuja Jayasinghe]

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.

>
>
>>
>>
>>
>>>
>>> [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 >>> > 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 the already configured
> authentication flow it its the only authenticator in that flow.
> And these authentication steps may be configured according to
> organization requirements, So I think there can be issues if we change
> automatically.
>

 Thats their requirement by deleting the IdP. We need to give them a
 warning - and probably show the associated IdPs - and then after
 confirmation delete.

>>> I prefer to give a warning and show ass

Re: [Architecture] Define Username Claim in Domain Level

[Thanuja Jayasinghe]

On Sun, Mar 19, 2017 at 2:10 PM, Gayan Gunawardana  wrote:

>
>
> On Wed, Mar 15, 2017 at 6:50 AM, Thanuja Jayasinghe 
> wrote:
>
>> Hi Nuwandi,
>>
>> On Tue, Mar 14, 2017 at 1:54 PM, Nuwandi Wickramasinghe <
>> nuwan...@wso2.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 14, 2017 at 12:42 PM, Thanuja Jayasinghe 
>>> wrote:
>>>
>>>> Hi Gayan,
>>>>
>>>> Yes. We need to specially handle username claim("
>>>> http://wso2.org/claims/username";).
>>>>
>>> So, it will always be http://wso2.org/claims/username, not configurable?
>>>
>>
>> I see following performance related concerns if we marked some claim as
>> the username claim using a property,
>>
>>
>>
>>- In every operation which we are going to specially handle for
>>username claim, we need to check that property
>>- If we want to get the username claim value, first we need to go
>>through claims to identify the username claim and then retrieve the value
>>for that claim
>>
>> Also, it will be much easier for the User object to retrieve username
>> claim from a claim URI rather than a property. (We don't have the API
>> support for retrieving claim value from a property)
>>
>> In a case like "email as username", we can still map the username claim
>> to the email attribute. Then we can map the same email attribute to email
>> claim to avoid the confusion.
>>
> if  "http://wso2.org/claims/username"; represent username claim always we
> do not need to define it separately in domain-config.yaml right ?
>
Yes.

@Pushpalanka: Are we planning to provide the capability to change root
claim dialect?

>
>>
>>>> Shall we add a method to User[1] class to retrieve username?
>>>>
>>> +1 to have a method in User.java
>>>
>>>>
>>>> [1] -  https://github.com/wso2/carbon-identity-mgt/blob/master/com
>>>> ponents/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/
>>>> carbon/identity/mgt/User.java
>>>>
>>>> Thanks,
>>>> Thanuja
>>>>
>>>> On Tue, Mar 14, 2017 at 12:12 PM, Gayan Gunawardana 
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Don't we have to provide an API to get username claim from domain
>>>>> level.
>>>>> I am suggesting to have some thing like
>>>>>
>>>>> org.wso2.carbon.identity.mgt.User userStoreUser = identityStore.
>>>>> getUser(userId);
>>>>> userStoreUser.getUsernameClaim();
>>>>>
>>>>> Currently we handle username claim as just an another claim but it
>>>>> should be treated as special claim because username is the human friendly
>>>>> unique identifier for users.
>>>>>
>>>>> In domain-config.yaml we can define username claim for each domain.
>>>>>
>>>>> Also another requirement is when we get username from out side
>>>>> application, we need to retrieve corresponding user from identity store so
>>>>> we need to set value got from out side to appropriate claim. In that case
>>>>> there should be a way to identify username claim.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks,
>>>>> Gayan
>>>>>
>>>>>
>>>>> --
>>>>> Gayan Gunawardana
>>>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>>>> Email: ga...@wso2.com
>>>>> Mobile: +94 (71) 8020933
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Thanuja Lakmal*
>>>> Senior Software Engineer
>>>> WSO2 Inc. http://wso2.com/
>>>> *lean.enterprise.middleware*
>>>> Mobile: +94715979891 +94758009992
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Best Regards,
>>>
>>> Nuwandi Wickramasinghe
>>>
>>> Software Engineer
>>>
>>> WSO2 Inc.
>>>
>>> Web : http://wso2.com
>>>
>>> Mobile : 0719214873
>>>
>>
>> Thanks,
>> Thanuja
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>
>
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>



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

Re: [Architecture] [C5][IS 6.0.0] User List UI for IS 6.0.0

[Thanuja Jayasinghe]

Hi Nuwandi,

On Tue, Mar 14, 2017 at 10:28 AM, Nuwandi Wickramasinghe 
wrote:

> Hi all,
>
> We are in the process of implementing User List view in the Admin Portal
> for the new IS 6.0.0 release. The wireframe design for the UI is found at
> [1].
>
> Admin can view a list of users and perform actions such as Delete, Edit
> and request to Reset Password. Also admin can select multiple users and
> chose to Delete, Disable or Activate. There will be an option to filter the
> list according to the user attributes.
>
> I am planning to add an admin profile in profile-mapping.yaml file where
> an admin can define what user attributes to be shown in the list.
>
> According to the wireframe ([1]), we have to give the flexibility to show
> Groups and Roles of the users. ATM we do not have claim definitions for
> Groups and Roles. Therefore we won't be able to handle them with an
> attribute profile. As per the offline chat with Johann we might define
> Claim URIs for Groups and Roles in future since there will be other use
> cases where we need to treat them as user attributes (eg. SAML attribute
> profile). Also loading all the Roles and Groups for each user in the list
> will highly effect the initial loading time. May be we can filter out to
> maximum number (say 3) of records and request all if one wants to see more
> roles/groups.
>

Can you give an example/use case where we need to define claims for a Role?


>
> However for the immediate release (m5) I guess it is ok not to have Roles
> and Groups in the User List view. We did not have that in IS 5.3.0 as well
> so I hope this is not a critical requirement. We will keep the wireframe as
> it is since we are planning to improve things in the future.
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.19%20User%20Listing.png
>
> thanks
> Nuwandi
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

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

Re: [Architecture] Define Username Claim in Domain Level

[Thanuja Jayasinghe]

Hi Indunil,

On Tue, Mar 14, 2017 at 7:42 PM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
>
> I think in a system, username claim is not a user specific detail, so that
> it's conceptually incorrect to define it in User level. It has to be
> configured globally or domain wise (So that based on the domain, the unique
> claim which use as the username can be configurable).
>

We're going to configure username domain wise.


> And also if we are adding a method in User object to get the user name
> claim, we can't have it in scenarios where User object is not available.
> Ex: When authenticating a user, need to pass the username claim [1] - from
> UI we can only get the values for user name and password and in order to
> get the username claim we don't have a User object
>

When you try to authenticate you are going to pass a unique claim with your
secret. So you don't need to have username claim for this operation.

After the authentication, we are returning the User object. Since we are
planning to provide a method to get username claim for User class, you can
directly call that method instead of going back to IdentityStore API.


>
> [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#L1628
>
> Thanks and Regards
>
> On Tue, Mar 14, 2017 at 1:54 PM, Nuwandi Wickramasinghe  > wrote:
>
>>
>>
>> On Tue, Mar 14, 2017 at 12:42 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi Gayan,
>>>
>>> Yes. We need to specially handle username claim("http://wso2.org/claims/
>>> username").
>>>
>> So, it will always be http://wso2.org/claims/username, not configurable?
>>
>>>
>>> Shall we add a method to User[1] class to retrieve username?
>>>
>> +1 to have a method in User.java
>>
>>>
>>> [1] -  https://github.com/wso2/carbon-identity-mgt/blob/master/com
>>> ponents/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/
>>> carbon/identity/mgt/User.java
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> On Tue, Mar 14, 2017 at 12:12 PM, Gayan Gunawardana 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Don't we have to provide an API to get username claim from domain
>>>> level.
>>>> I am suggesting to have some thing like
>>>>
>>>> org.wso2.carbon.identity.mgt.User userStoreUser = identityStore.
>>>> getUser(userId);
>>>> userStoreUser.getUsernameClaim();
>>>>
>>>> Currently we handle username claim as just an another claim but it
>>>> should be treated as special claim because username is the human friendly
>>>> unique identifier for users.
>>>>
>>>> In domain-config.yaml we can define username claim for each domain.
>>>>
>>>> Also another requirement is when we get username from out side
>>>> application, we need to retrieve corresponding user from identity store so
>>>> we need to set value got from out side to appropriate claim. In that case
>>>> there should be a way to identify username claim.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks,
>>>> Gayan
>>>>
>>>>
>>>> --
>>>> Gayan Gunawardana
>>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>>> Email: ga...@wso2.com
>>>> Mobile: +94 (71) 8020933
>>>>
>>>
>>>
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>
>>
>>
>> --
>>
>> Best Regards,
>>
>> Nuwandi Wickramasinghe
>>
>> Software Engineer
>>
>> WSO2 Inc.
>>
>> Web : http://wso2.com
>>
>> Mobile : 0719214873
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Emailindu...@wso2.com
> Mobile   0772182255
>

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

Re: [Architecture] Define Username Claim in Domain Level

[Thanuja Jayasinghe]

Hi Nuwandi,

On Tue, Mar 14, 2017 at 1:54 PM, Nuwandi Wickramasinghe 
wrote:

>
>
> On Tue, Mar 14, 2017 at 12:42 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi Gayan,
>>
>> Yes. We need to specially handle username claim("http://wso2.org/claims/
>> username").
>>
> So, it will always be http://wso2.org/claims/username, not configurable?
>

I see following performance related concerns if we marked some claim as the
username claim using a property,



   - In every operation which we are going to specially handle for username
   claim, we need to check that property
   - If we want to get the username claim value, first we need to go
   through claims to identify the username claim and then retrieve the value
   for that claim

Also, it will be much easier for the User object to retrieve username claim
from a claim URI rather than a property. (We don't have the API support for
retrieving claim value from a property)

In a case like "email as username", we can still map the username claim to
the email attribute. Then we can map the same email attribute to email
claim to avoid the confusion.


>> Shall we add a method to User[1] class to retrieve username?
>>
> +1 to have a method in User.java
>
>>
>> [1] -  https://github.com/wso2/carbon-identity-mgt/blob/master/com
>> ponents/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/
>> carbon/identity/mgt/User.java
>>
>> Thanks,
>> Thanuja
>>
>> On Tue, Mar 14, 2017 at 12:12 PM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> Don't we have to provide an API to get username claim from domain level.
>>> I am suggesting to have some thing like
>>>
>>> org.wso2.carbon.identity.mgt.User userStoreUser = identityStore.
>>> getUser(userId);
>>> userStoreUser.getUsernameClaim();
>>>
>>> Currently we handle username claim as just an another claim but it
>>> should be treated as special claim because username is the human friendly
>>> unique identifier for users.
>>>
>>> In domain-config.yaml we can define username claim for each domain.
>>>
>>> Also another requirement is when we get username from out side
>>> application, we need to retrieve corresponding user from identity store so
>>> we need to set value got from out side to appropriate claim. In that case
>>> there should be a way to identify username claim.
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> Gayan
>>>
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>
>>
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>
>
>
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>

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

Re: [Architecture] Define Username Claim in Domain Level

[Thanuja Jayasinghe]

Hi Gayan,

Yes. We need to specially handle username claim("
http://wso2.org/claims/username";).

Shall we add a method to User[1] class to retrieve username?

[1] -  https://github.com/wso2/carbon-identity-mgt/blob/
master/components/org.wso2.carbon.identity.mgt/src/main/
java/org/wso2/carbon/identity/mgt/User.java

Thanks,
Thanuja

On Tue, Mar 14, 2017 at 12:12 PM, Gayan Gunawardana  wrote:

> Hi All,
>
> Don't we have to provide an API to get username claim from domain level.
> I am suggesting to have some thing like
>
> org.wso2.carbon.identity.mgt.User userStoreUser = identityStore.
> getUser(userId);
> userStoreUser.getUsernameClaim();
>
> Currently we handle username claim as just an another claim but it should
> be treated as special claim because username is the human friendly unique
> identifier for users.
>
> In domain-config.yaml we can define username claim for each domain.
>
> Also another requirement is when we get username from out side
> application, we need to retrieve corresponding user from identity store so
> we need to set value got from out side to appropriate claim. In that case
> there should be a way to identify username claim.
>
> WDYT?
>
> Thanks,
> Gayan
>
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>



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

Re: [Architecture] Claim dialect must have two special attributes indicating "userid" claim URI and "role" claim URI.

[Thanuja Jayasinghe]

On Sat, Mar 11, 2017 at 11:33 AM, Johann Nallathamby 
wrote:

>
>
> On Sat, Mar 11, 2017 at 8:58 AM, Thanuja Jayasinghe 
> wrote:
>
>> Hi Johann,
>>
>> We use same "claim management" in SP configuration as well. So these
>> attributes will be available for them also. When it comes to "userid", two
>> SPs which use same claim configuration can have two different claims.
>>
>
> No. Two SPs can request two different claims as the Subject. But the
> unique user identifier claim must be specific to the dialect. E.g. SCIM 2.0
> defines "userName" as the human-friendly unique identifier for the user.
> SCIM 2.0 in fact defines the "id" claim also which is a non-human-friendly
> unique identifier for a user. Although we don't need to support multiple
> unique identifiers we at least need to support one so that it will be the
> default subject if user doesn't select any other claim.
>

So, we also provide the ovridding capability at the SP configuration level?


>
>
>>
>> So, to avoid the confusion shall we rename it to something like
>> "feduserid"?
>>
>
> If we go by my above explanation this is not required.
>
>
>>
>> Thanks,
>>
>> On Mon, Mar 6, 2017 at 3:09 AM, Johann Nallathamby 
>> wrote:
>>
>>> Hi All,
>>>
>>> Any foreign dialect that we define using claim management, must have two
>>> special attributes indicating the "userid" claim and the "role" claim.
>>>
>>> "userid" claim is required for use cases like authentication and
>>> provisioning. "role" claim is needed for role mapping and access control.
>>>
>>> In C4 we had this at the IDP configuration level. In C5, since we have
>>> extracted all the claim configuration from IDP to "claim management", and
>>> just refer to the dialect alone in IDP configuration, we need to identify
>>> these two special attributes also in the claim dialect management level.
>>> This configuration will be fixed for any real IDP.
>>>
>>> What are your ideas?
>>>
>>> --
>>> 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>*
>>>
>>
>>
>>
>> --
>> *Thanuja Lakmal*
>> Senior Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891 +94758009992
>>
>
>
>
> --
> 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>*
>



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

Re: [Architecture] [C5][IS] Get claims from User object when it is get from cache.

[Thanuja Jayasinghe]

As per my understanding, If you get a cached user object from the
IdenttityStroe cached wrapper, then the wrapper is responsible for setting
the identity store object to the deserialized user object. So that the
calling party will not see any difference.

As a summary,

   - Only IdentityStore cached wrapper stores user objects
   - After retrieving a user object from the cache, IdentityStore cached
   wrapper is responsible for setting the IdentityStore instance to the
   deserialized User object.
   - Any other component outside user-core should only cache uniqueUserId
   and should always come back to the user-core for User object


Thanks,
Thanuja

On Sat, Mar 11, 2017 at 11:46 PM, Johann Nallathamby 
wrote:

> Why can't we simply re-initialize the User object with the correct
> identity store when it is deserialized, using the readObject() method?
>
> On Sat, Mar 11, 2017 at 10:41 PM, Jayanga Kaushalya 
> wrote:
>
>> Hi Harsha,
>>
>> Yes I understand. Either you have to check whether the Identity Store is
>> null in the User object or we should change each method in the User class
>> which uses Identity Store to throw custom checked exception when the
>> Identity Store is null and handle it accordingly when using User object.
>> Personally I am +1 for the second approach. Please advice if there are any
>> better approaches.
>>
>> Thanks!
>>
>> *Jayanga Kaushalya*
>> Software Engineer
>> Mobile: +94777860160 <+94%2077%20786%200160>
>> WSO2 Inc. | http://wso2.com
>> lean.enterprise.middleware
>>
>> On Sat, Mar 11, 2017 at 9:27 PM, Harsha Thirimanna 
>> wrote:
>>
>>> Hi Jayanga,
>>>
>>> Yes, that is possible to do and I felt it as a workaround to instead of
>>> calling getClaim API in user object.
>>> But at once i didn't feel that i can't call getClaim API because i don't
>>> know  whether that User object is coming from Cache or not. It can be
>>> cached by different component even.
>>> Is that make sense to provide such API in user object if it not possible
>>> to give the result all the time in sameway. We have to make it consistent.
>>> Because , the developer has to know whether this User object came from
>>> Cache or not. If it is from cache, then developer has to get the claims by
>>> using RealmService again.
>>>
>>> *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
>>> 
>>>
>>> On Sat, Mar 11, 2017 at 8:49 PM, Hasintha Indrajee 
>>> wrote:
>>>
 Hi Jayanga,

 So what happens if we want to store user objects and then later if we
 want to retrieve user objects and try to access claims ? . Here we are
 storing user objects in authentication context, not in the identity store.
 And how are we storing user objects in the cache when the instance of
 identity store is neither serializable nor transient ?

 On Sat, Mar 11, 2017 at 8:34 PM, Jayanga Kaushalya 
 wrote:

> Hi Harsha,
>
> It was designed to be like that. User object will be cached in the
> IdentityStore. So when you retrieving the user object from IdentityStore
> again, it will be most probably from cache instead of connector.
>
> Thanks!
>
> *Jayanga Kaushalya*
> Software Engineer
> Mobile: +94777860160 <+94%2077%20786%200160>
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>
> On Sat, Mar 11, 2017 at 7:41 PM, Harsha Thirimanna 
> wrote:
>
>> Hi All,
>>
>> In identity gateway, we have to cache the User object that is
>> retrieved from user core within the authentication context and session
>> context. After some times we have to get that user object and want to get
>> the claims since it has the claim API within user object itself. But
>> because of the IdentityStore is non Serializable and make it
>> transient, it will not stored with the User object when it cached,
>> so we can't call the getCalim method in User object now.
>>
>> What I did is, get the user unique id from the user object that is
>> stored in the cache and call the RealmService and get the User object 
>> again
>> from the user core when it required. Is that the right behaviour that we
>> expect in the new user core design or did I missed something ?
>>
>>
>> public class User implements Serializable {
>> private static final long serialVersionUID = 21578845544565554L;
>> private String uniqueUserId;
>> private String domainName;
>> private String state;
>> private transient IdentityStore identityStore;
>>
>> thanks
>>
>> *Harsha Thirimanna*
>> *Associate Tech Lead | WSO2*
>>
>> Email: hars...@wso2.com
>> Mob: +94715186770 <

Re: [Architecture] Claim dialect must have two special attributes indicating "userid" claim URI and "role" claim URI.

[Thanuja Jayasinghe]

Hi Johann,

We use same "claim management" in SP configuration as well. So these
attributes will be available for them also. When it comes to "userid", two
SPs which use same claim configuration can have two different claims.

So, to avoid the confusion shall we rename it to something like "feduserid"?

Thanks,

On Mon, Mar 6, 2017 at 3:09 AM, Johann Nallathamby  wrote:

> Hi All,
>
> Any foreign dialect that we define using claim management, must have two
> special attributes indicating the "userid" claim and the "role" claim.
>
> "userid" claim is required for use cases like authentication and
> provisioning. "role" claim is needed for role mapping and access control.
>
> In C4 we had this at the IDP configuration level. In C5, since we have
> extracted all the claim configuration from IDP to "claim management", and
> just refer to the dialect alone in IDP configuration, we need to identify
> these two special attributes also in the claim dialect management level.
> This configuration will be fixed for any real IDP.
>
> What are your ideas?
>
> --
> 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 *
>



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

Re: [Architecture] Claim dialect must have two special attributes indicating "userid" claim URI and "role" claim URI.

[Thanuja Jayasinghe]

Hi Isuru,

On Wed, Mar 8, 2017 at 9:08 AM, Isuru Haththotuwa  wrote:

> Hi Johann,
>
> On Mon, Mar 6, 2017 at 3:09 AM, Johann Nallathamby 
> wrote:
>
>> Hi All,
>>
>> Any foreign dialect that we define using claim management, must have two
>> special attributes indicating the "userid" claim and the "role" claim.
>>
>> "userid" claim is required for use cases like authentication and
>> provisioning. "role" claim is needed for role mapping and access control.
>>
> Apologies if this is something obvious, what exactly does the user id mean
> in a claim context? Is it related to the issuer, or the subject?
>

It's the subject value(authenticated user id) of the authentication
response.


>
>>
>> In C4 we had this at the IDP configuration level. In C5, since we have
>> extracted all the claim configuration from IDP to "claim management", and
>> just refer to the dialect alone in IDP configuration, we need to identify
>> these two special attributes also in the claim dialect management level.
>> This configuration will be fixed for any real IDP.
>>
>> What are your ideas?
>>
>> --
>> 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
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048 <+94%2071%20635%208048>* *
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

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

Re: [Architecture] Paginate and Filter Entries in IS 6.0.0

[Thanuja Jayasinghe]

Hi Gayan,

On Thu, Mar 2, 2017 at 9:58 AM, Gayan Gunawardana  wrote:

>
> Hi All,
>
> How listUsers, listGroups methods should behave when domain is not
> specified ?
>
>
> *1. listUsers(int offset, int length)*
> Take primary domain as user store domain and provide paginated result.
>
>
> *2. listUsers(Claim claim, int offset, int length)*Take primary domain as
> user store domain and provide paginated, filtered result.
>
>
> *3. listUsers(MetaClaim metaClaim, String filterPattern, int offset, int
> length)*Take primary domain as user store domain and provide paginated,
> filtered result.
>
>
> *4. listUsers(List claims, int offset, int length)*
> Iterate through all user store domains and provide paginated, filtered
> result.
>
> IMO behavior of *1* is correct but *2, 3, 4 need to be *consistent. I
> think *2, 3 *also behave as *4*. Please correct me If I am wrong.
>


*2, 3 Cases -*

Searching using a claim or meta-claim are high-cost operations to the DB
(or whatever connector). Complexity of these operations are as follows,

- How to decide offset? you have to search through each domain for that
claim/meta-claim until you meet the offset
- Need to get Unique user id for each connector user id found in the search
so multiple calls need to be made to the each domain unique id resolvers
- Added complexity in the pagination

So this operation will consume lot of DB resources, ultimately slowing down
other operations

*4 Case -*

This also should behave like 2 and 3 cases. Otherwise, we will face above
mentioned problems.



>
> Thanks,
> Gayan
>
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>


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

Re: [Architecture] IdentityStore APIs in C5

[Thanuja Jayasinghe]

Hi Gayan,

We have already defined an exception hierarchy for identity components.

IdentityException[1]
├── IdentityServerException[2]
└── IdentityClientException[3]

 All exceptions classes defined for identity components extend either
IdentityServerException
or IdentityClientException.

So any client can catch the exception as follows,

catch (IdentityClientException ex) {
// Can return the same error message and code to the client
} catch (IdentityException ex) {
// Need to log and return a generic message to the client
}

Since we add these exception classes recently, we need to
update carbon-identity-mgt repo.

[1] -
https://github.com/wso2/carbon-identity-commons/blob/master/components/org.wso2.carbon.identity.common/src/main/java/org/wso2/carbon/identity/common/base/exception/IdentityException.java
[2] -
https://github.com/wso2/carbon-identity-commons/blob/master/components/org.wso2.carbon.identity.common/src/main/java/org/wso2/carbon/identity/common/base/exception/IdentityServerException.java
[3] -
https://github.com/wso2/carbon-identity-commons/blob/master/components/org.wso2.carbon.identity.common/src/main/java/org/wso2/carbon/identity/common/base/exception/IdentityClientException.java

Thanks,
Thanuja

On Mon, Feb 27, 2017 at 10:06 AM, Ruwan Abeykoon  wrote:

> Hi All,
> +1 to have an exception hierarchy, which carries information for specific
> errors.
>
> I think we should follow the way Java IO exceptions are done.
>
> Cheers,
> Ruwan
>
>
> On Mon, Feb 27, 2017 at 9:58 AM, Gayan Gunawardana  wrote:
>
>> Hi All,
>>
>> Shall we revisit IdentityStore APIs? For an example addUser method[1]
>> throws IdentityStoreClientException and IdentityStoreServerException in
>> many cases where client cannot differentiate the reason. There will be
>> relevant error message but client cannot rely on error message to take
>> decisions.
>> IMO we should have proper exception hierarchy or error codes. I'm +1 to
>> have
>> exception hierarchy.
>>
>> 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#L985
>>
>> Thanks,
>> Gayan
>> --
>> Gayan Gunawardana
>> Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>
>
>
> --
>
> *Ruwan Abeykoon*
> *Associate Director/Architect**,*
> *WSO2, Inc. http://wso2.com  *
> *lean.enterprise.middleware.*
>
>


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

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

[Thanuja Jayasinghe]

Hi Johann / Isura,

On Tue, Feb 7, 2017 at 10:00 PM, Johann Nallathamby  wrote:

>
>
> On Wed, Feb 8, 2017 at 9:25 AM, Isura Karunaratne  wrote:
>
>> 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
>> ?
>>
>
> 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?


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

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

Re: [Architecture] Dashboard Component Permission Model

[Thanuja Jayasinghe]

Hi Johann/Napagoda,

KasunG is currently working on removing user.core components from the
carbon-security repo. So we will have carbon-security m3 release before the
IS 6.0.0 m1 release.

Thanks,
Thanuja


On Fri, Jan 20, 2017 at 9:58 AM, Johann Nallathamby  wrote:

>
>
> On Mon, Jan 9, 2017 at 2:21 PM, Thanuja Jayasinghe 
> wrote:
>
>>
>>
>> On Mon, Jan 9, 2017 at 1:34 PM, SajithAR Ariyarathna 
>> wrote:
>>
>>> Currently, we are in the process of refactoring the carbon-security
>>>> source and hope to release a 1.0.0-m3 soon. With this release, CAAS User
>>>> implementation will only provide authorization functionalities. In order to
>>>> consume identity store related functionalities, you need to use the User
>>>> class provided by carbon-identity-mgt[1]. Also, both classes will implement
>>>>  Serializable.
>>>>
>>>> [1] - https://github.com/thanujalk/carbon-identity-mgt/blob/mast
>>>> er/components/org.wso2.carbon.identity.mgt/src/main/java/org
>>>> /wso2/carbon/identity/mgt/User.java
>>>>
>>> So, which class will provide the isAuthorized(Permission permission)
>>>  method?
>>>
>>> It is the class which we have inside the CAAS. Basically User class in
>> the carbon-identity-mgt is a child of CAAS User.
>>
>
> Thanuja, are we not removing the user.core implementation from
> carbon-security and just have it in carbon-identity-mgt? I thought in IS
> 6.0.0 M1 release that is how it will be. So we will only have one User
> class hereafter. Is my understanding wrong?
>
>
>> On Mon, Jan 9, 2017 at 1:05 PM, Thanuja Jayasinghe 
>>> wrote:
>>>
>>>> Hi Sajith,
>>>>
>>>> Currently, we are in the process of refactoring the carbon-security
>>>> source and hope to release a 1.0.0-m3 soon. With this release, CAAS User
>>>> implementation will only provide authorization functionalities. In order to
>>>> consume identity store related functionalities, you need to use the User
>>>> class provided by carbon-identity-mgt[1]. Also, both classes will implement
>>>>  Serializable.
>>>>
>>>> [1] - https://github.com/thanujalk/carbon-identity-mgt/blob/mast
>>>> er/components/org.wso2.carbon.identity.mgt/src/main/java/org
>>>> /wso2/carbon/identity/mgt/User.java
>>>>
>>>> Thanks,
>>>> Thanuja
>>>>
>>>> On Mon, Jan 9, 2017 at 12:45 PM, SajithAR Ariyarathna <
>>>> sajit...@wso2.com> wrote:
>>>>
>>>>> Hi Johann,
>>>>>
>>>>> Once you login using CAAS (carbon authentication and authorization
>>>>>> service) components you will get a CAAS User object [1]. This User object
>>>>>> is a proxy object which can be used to call all the underlying identity
>>>>>> store and authorization store methods. Ideally you will store this User
>>>>>> object in the user's logged in session and perform those operations when
>>>>>> necessary.
>>>>>>
>>>>>> [1] https://github.com/wso2/carbon-security/blob/release-1.0
>>>>>> .0-m2/components/org.wso2.carbon.security.caas/src/main/java
>>>>>> /org/wso2/carbon/security/caas/user/core/bean/User.java
>>>>>>
>>>>> This means that we need to store the User object in the UUF session.
>>>>> In order to that the User class needs to be serializable. However
>>>>> User class does not implements Serializable interface.
>>>>>
>>>>> On Wed, Jan 4, 2017 at 3:13 PM, Tanya Madurapperuma 
>>>>> wrote:
>>>>>
>>>>>> Hi Dilan,
>>>>>>
>>>>>> On Wed, Jan 4, 2017 at 2:48 PM, Dilan Udara Ariyaratne <
>>>>>> dil...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi Tania,
>>>>>>>
>>>>>>> Are we going to keep one dashboard permission or multiple ? The
>>>>>>> reason that I am asking this is if we can allow multiple, we can
>>>>>>> separate out access for critical functions like dashboard view, edit
>>>>>>> and manage via those permissions.
>>>>>>>
>>>>>> As explained offline each dashboard will have its own permission for
>>>>>> view , edit/ update, delete. The only difference in this with the 
>>>>>> previous
>&

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

[Thanuja Jayasinghe]

Hi,

Tested following,

   - Account recovery with notification
   - Account recovery with security questions
   - Recaptcha
   - Self signup

[+] Stable - go ahead and release

Thanks,
Thanuja

On Mon, Jan 9, 2017 at 11:05 AM, Rushmin Fernando  wrote:

> Tested following features with MSSQL
>
> 1) SAML flow
> 2) OAuth
> 3) OIDC
> 4) SAML metedata profile
>
>   [+] Stable - go ahead and release
>
> Best Regards
> Rushmin
>
> 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/prod
>>> uct-is/releases/tag/v5.3.0-rc3
>>> Analytics : https://github.com/wso2/anal
>>> ytics-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
>>
>>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc.  - Lean . Enterprise . Middleware
>
> mobile : +94775615183
>
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


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

Re: [Architecture] Dashboard Component Permission Model

[Thanuja Jayasinghe]

On Mon, Jan 9, 2017 at 1:34 PM, SajithAR Ariyarathna 
wrote:

> Currently, we are in the process of refactoring the carbon-security source
>> and hope to release a 1.0.0-m3 soon. With this release, CAAS User
>> implementation will only provide authorization functionalities. In order to
>> consume identity store related functionalities, you need to use the User
>> class provided by carbon-identity-mgt[1]. Also, both classes will implement
>>  Serializable.
>>
>> [1] - https://github.com/thanujalk/carbon-identity-mgt/blob/
>> master/components/org.wso2.carbon.identity.mgt/src/main/
>> java/org/wso2/carbon/identity/mgt/User.java
>>
> So, which class will provide the isAuthorized(Permission permission)
>  method?
>
> It is the class which we have inside the CAAS. Basically User class in the
carbon-identity-mgt is a child of CAAS User.

> On Mon, Jan 9, 2017 at 1:05 PM, Thanuja Jayasinghe 
> wrote:
>
>> Hi Sajith,
>>
>> Currently, we are in the process of refactoring the carbon-security
>> source and hope to release a 1.0.0-m3 soon. With this release, CAAS User
>> implementation will only provide authorization functionalities. In order to
>> consume identity store related functionalities, you need to use the User
>> class provided by carbon-identity-mgt[1]. Also, both classes will implement
>>  Serializable.
>>
>> [1] - https://github.com/thanujalk/carbon-identity-mgt/blob/
>> master/components/org.wso2.carbon.identity.mgt/src/main/
>> java/org/wso2/carbon/identity/mgt/User.java
>>
>> Thanks,
>> Thanuja
>>
>> On Mon, Jan 9, 2017 at 12:45 PM, SajithAR Ariyarathna 
>> wrote:
>>
>>> Hi Johann,
>>>
>>> Once you login using CAAS (carbon authentication and authorization
>>>> service) components you will get a CAAS User object [1]. This User object
>>>> is a proxy object which can be used to call all the underlying identity
>>>> store and authorization store methods. Ideally you will store this User
>>>> object in the user's logged in session and perform those operations when
>>>> necessary.
>>>>
>>>> [1] https://github.com/wso2/carbon-security/blob/release-1.0
>>>> .0-m2/components/org.wso2.carbon.security.caas/src/main/java
>>>> /org/wso2/carbon/security/caas/user/core/bean/User.java
>>>>
>>> This means that we need to store the User object in the UUF session. In
>>> order to that the User class needs to be serializable. However User
>>> class does not implements Serializable interface.
>>>
>>> On Wed, Jan 4, 2017 at 3:13 PM, Tanya Madurapperuma 
>>> wrote:
>>>
>>>> Hi Dilan,
>>>>
>>>> On Wed, Jan 4, 2017 at 2:48 PM, Dilan Udara Ariyaratne >>> > wrote:
>>>>
>>>>> Hi Tania,
>>>>>
>>>>> Are we going to keep one dashboard permission or multiple ? The reason
>>>>> that I am asking this is if we can allow multiple, we can
>>>>> separate out access for critical functions like dashboard view, edit
>>>>> and manage via those permissions.
>>>>>
>>>> As explained offline each dashboard will have its own permission for
>>>> view , edit/ update, delete. The only difference in this with the previous
>>>> versions is that instead of the role we will use permissions.
>>>>
>>>>>
>>>>> Also, have you looked into the scenario of restricting access of
>>>>> dashboards for different users ?
>>>>>
>>>> A permission is resource + action. So we can restrict access with the
>>>> permission.
>>>>
>>>>> AFAIU, it's only by having multiple permissions, we can do this.
>>>>>
>>>>
>>>> Thanks,
>>>> Tanya
>>>>
>>>>>
>>>>> Cheers,
>>>>> Dilan.
>>>>>
>>>>> *Dilan U. Ariyaratne*
>>>>> Senior Software Engineer
>>>>> WSO2 Inc. <http://wso2.com/>
>>>>> Mobile: +94766405580 <%2B94766405580>
>>>>> lean . enterprise . middleware
>>>>>
>>>>>
>>>>> On Wed, Jan 4, 2017 at 1:56 PM, Johann Nallathamby 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 4, 2017 at 1:04 PM, Nipuna Chandradasa 
>>>>>> wrote:
>>>>>>
>>>>>>> [+adding Sajith

Re: [Architecture] Dashboard Component Permission Model

[Thanuja Jayasinghe]

Hi Sajith,

Currently, we are in the process of refactoring the carbon-security source
and hope to release a 1.0.0-m3 soon. With this release, CAAS User
implementation will only provide authorization functionalities. In order to
consume identity store related functionalities, you need to use the User
class provided by carbon-identity-mgt[1]. Also, both classes will implement
Serializable.

[1] -
https://github.com/thanujalk/carbon-identity-mgt/blob/master/components/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/carbon/identity/mgt/User.java

Thanks,
Thanuja

On Mon, Jan 9, 2017 at 12:45 PM, SajithAR Ariyarathna 
wrote:

> Hi Johann,
>
> Once you login using CAAS (carbon authentication and authorization
>> service) components you will get a CAAS User object [1]. This User object
>> is a proxy object which can be used to call all the underlying identity
>> store and authorization store methods. Ideally you will store this User
>> object in the user's logged in session and perform those operations when
>> necessary.
>>
>> [1] https://github.com/wso2/carbon-security/blob/release-1.0
>> .0-m2/components/org.wso2.carbon.security.caas/src/main/java
>> /org/wso2/carbon/security/caas/user/core/bean/User.java
>>
> This means that we need to store the User object in the UUF session. In
> order to that the User class needs to be serializable. However User class
> does not implements Serializable interface.
>
> On Wed, Jan 4, 2017 at 3:13 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi Dilan,
>>
>> On Wed, Jan 4, 2017 at 2:48 PM, Dilan Udara Ariyaratne 
>> wrote:
>>
>>> Hi Tania,
>>>
>>> Are we going to keep one dashboard permission or multiple ? The reason
>>> that I am asking this is if we can allow multiple, we can
>>> separate out access for critical functions like dashboard view, edit and
>>> manage via those permissions.
>>>
>> As explained offline each dashboard will have its own permission for view
>> , edit/ update, delete. The only difference in this with the previous
>> versions is that instead of the role we will use permissions.
>>
>>>
>>> Also, have you looked into the scenario of restricting access of
>>> dashboards for different users ?
>>>
>> A permission is resource + action. So we can restrict access with the
>> permission.
>>
>>> AFAIU, it's only by having multiple permissions, we can do this.
>>>
>>
>> Thanks,
>> Tanya
>>
>>>
>>> Cheers,
>>> Dilan.
>>>
>>> *Dilan U. Ariyaratne*
>>> Senior Software Engineer
>>> WSO2 Inc. 
>>> Mobile: +94766405580 <%2B94766405580>
>>> lean . enterprise . middleware
>>>
>>>
>>> On Wed, Jan 4, 2017 at 1:56 PM, Johann Nallathamby 
>>> wrote:
>>>


 On Wed, Jan 4, 2017 at 1:04 PM, Nipuna Chandradasa 
 wrote:

> [+adding Sajith]
> Please find the my questions and suggestions in line
>
>>
 Based on the above model we have following questions.
 1. How can we call the isAuthorized method from dashboard component
 ?

>>>
> Isn't this isAuthorized method should be exposed through UUF as
> dashboard component is basically a UUF component? It might not be good to
> expose a such a functionality through a UI framework but it'll be lot
> cleaner than invoking a OSGI service inside our component.
>

 Once you login using CAAS (carbon authentication and authorization
 service) components you will get a CAAS User object [1]. This User object
 is a proxy object which can be used to call all the underlying identity
 store and authorization store methods. Ideally you will store this User
 object in the user's logged in session and perform those operations when
 necessary.

 [1] https://github.com/wso2/carbon-security/blob/release-1.0
 .0-m2/components/org.wso2.carbon.security.caas/src/main/java
 /org/wso2/carbon/security/caas/user/core/bean/User.java

 Regards,
 Johann.



>
>
>> 2. Is there any standard / approval process for permission strings ?

>>> 3. How should we register the permissions dynamically at the time of
 creating a dashboard?

 Appreciate your insight.

>>>
>>>
> Thank you,
>
> --
> Nipuna Marcus
> *Software Engineer*
> WSO2 Inc.
> http://wso2.com/ - "lean . enterprise . middleware"
> Mobile : +94 (0) 713 667906 <+94%2071%20366%207906>
> nipu...@wso2.com
>



 --
 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] [IS 6.0.0] Unique User Id for Identity Store

[Thanuja Jayasinghe]

Hi All,

In the IS 6.0.0 Identity Store design we facilitate to have multiple user
domains, each contains one or more identity/credential store connectors.
Also, same identity/credential store connector may reside in two different
domains. So there is a requirement to identify a user uniquely throughout
the system.

*Approach One*

Calculate unique user id as a combination of domain id and connector wise
user mappings. Use a signing mechanism to ensure the integrity of the id.

Ex: {domain-id}.{connector-id : connector-user-id}*.{digest-value} =>
12.{c1:ad...@wso2.com}{c2:78451244}.W4sU2s

Pros:

   - Can verify the user without a database call by recalculating the
   digest value of the id.
   - Can identify the domain and connector wise mapping without a database
   call if server received the id.

Cons:

   - If a connector added or removed from the domain, then the unique id
   will be a different one. So need to have a constraint there.
   - In a scenario where we have multiple connectors, during a user claim
   update, some connectors may be added to the id. Since when we create a user
   we may not add attributes to all the connectors.
   - Having a valid unique user id does not guarantee that user still
   exists in the system.
   - Unique id may be lengthy.


*Approach Two*

Calculate unique user id as a combination of domain id and a random UUID.

Ex: {domain-id}.{random-uuid} => 12.A1j88KlmSKAl74

Pros:

   - Can identify the domain without a database call.
   - Can add or remove connectors without changing the unique user id.
   - User claim update does not affect the unique user id value.
   - Fairly small id compared to the approach one.


Cons:

   - Need a database call to get the connector mappings.


It feels like approach two is more suitable for the identity store. WDYT?

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

[Architecture] [IS] Securing IS REST APIs from brute force attacks

[Thanuja Jayasinghe]

Hi All,

I'm working on $subject.

Some of the REST APIs which we are going to introduce with IS 5.3.0
release, will need some extra protection against bot attacks.

API Requirement Prevention mechanisms
Self sign-up Human verification captcha/reCaptcha
Password recovery with email Human verification captcha/reCaptcha
Password recovery with challenge questions Prevent brute force attacks to
identify the answer captcha/reCaptcha after n number of failed attempts
Lock account after m(>n) failed attempts


*The requirement for new REST API?*

Conditions to enable any prevention mechanism is different from one
scenario to another. So API consumer needs to know current security
mechanism for a particular API, before engaging it. Also APIs with one
method like 'password recovery with email', raise the problem how to inform
the API consumer about the current security mechanism?

A solution will be having a separate API to get this information. This API
will provide following resources,

   - Resource to get current security mechanism + related properties by
   providing target resource and optionally user.
   - Resource to evaluate enabled security mechanism and generate a
   confirmation key


*How to define security mechanism for REST API?*

we can have a UI as follows to define prevention mechanism for each API,


​
This UI defines what are the *possible* mechanisms for selected context
path. If there are no user selection mechanism, it means we can apply this
by default for that context path(Ex: enable reCapatcha by default for self
sign-up ). If a user is involved, the *applicability* of security
mechanisms may get differ depend on the role ,user store, and value of some
user claims. So we need a policy based mechanism to handle user related
scenarios.

Since we already have support for *XACML*, we may able to write required
policies in XACML and evaluate them through queries?. If it returns
'PERMIT' we can apply the selected security mechanism for the context path
for that user. Also, we can provide this as an extension point where other
implementations for policy evaluation can plug. XACML will be one
implementation.

*Where can we enforce this?*

We are going to have a filter which will intercept all requests and pass
them to the relevant connector which can handle the scenario. Connector
selection will happen based on context path and connector will evaluate
current security mechanism using a similar approach as above and will
validate confirmation key comes as a request header. If a request failed to
satisfy enabled security measures, a common error message will return to
the API consumer.

In a scenario where security mechanism get enabled after n number of
attempts (Ex: password recovery with challenge questions), the filter will
inform API consumer whether a security mechanism enabled for the next step
via a header. Then the API consumer(Ex: web app) can contact the above rest
API and get info about the enabled security mechanism.


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

Re: [Architecture] Monitor Logged In Users/Sessions

[Thanuja Jayasinghe]

On Tue, Jul 5, 2016 at 8:25 PM, Prabath Siriwardana 
wrote:

> Also please note that we do not store USER_DOMAIN_NAME, but the
> USERSTORE_DOMAIN_ID...
>

Practise we follow in other components is, keep 'USER_DOMAIN_NAME' in the
table and use 'org
.wso2.carbon.identity.user.store.configuration.listener.AbstractUserStoreConfigListener'
to
handle any modification or deletion.


>
> Thanks & regards,
> -Prabath
>
> On Sun, Jul 3, 2016 at 10:01 PM, Gayan Gunawardana  wrote:
>
>>
>>
>> On Mon, Jul 4, 2016 at 9:31 AM, Selvaratnam Uthaiyashankar <
>> shan...@wso2.com> wrote:
>>
>>>
>>>
>>>

 On Fri, Jul 1, 2016 at 7:32 PM, Selvaratnam Uthaiyashankar <
 shan...@wso2.com> wrote:

>
>
> On Mon, Jun 27, 2016 at 3:53 PM, Gayan Gunawardana 
> wrote:
>
>> Hi All,
>>
>> This feature will provide capability to admin users to monitor other
>> logged in users sessions and kill those sessions if necessary. Currently
>> logged in users sessions persist inside IDN_AUTH_SESSION_STORE table and
>> there is no mapping to authenticated user. We are planning to introduce 
>> new
>> table to maintain mapping between user and session id.
>>
>> CREATE TABLE IDN_USER_SESSION_DATA (
>>
>>   SESSION_ID VARCHAR (100) DEFAULT NULL,
>>
>>   USER_NAME VARCHAR(100) DEFAULT NULL,
>>
>>   USER_DOMAIN_NAME VARCHAR(100) DEFAULT NULL,
>>
>>   TENANT_NAME VARCHAR(100) DEFAULT NULL,
>>
>
> In all other tables, we keep TENANT_ID, not the TENANT_NAME. Any
> reason we have TENANT_NAME here and not TENANT_ID?
>

 Reason to use TENANT_NAME instead of TENANT_ID is we retrieve user
 tenant information from SessionContextCacheEntry --> SequenceConfig -->
 AuthenticatedUser there we don't have TENANT_ID information. I will look
 into possibility of using TENANT_ID instead of TENANT_NAME.

>
>
>
>>
>>   FOREIGN KEY (SESSION_ID) REFERENCES
>> IDN_AUTH_SESSION_STORE(SESSION_ID) ON DELETE CASCADE,
>>
>>   PRIMARY KEY (SESSION_ID, USER_NAME)
>>
>
>
> Is it possible for a SESSION_ID to have multiple USER_NAME? if not,
> above primary key doesn't make sense.
>
 Yes. It is possible to have multiple USER_NAME for SESSION_ID.

>>>
>>>
>>> Can you give an example of a situation where you can have a single
>>> SESSION_ID and different USER_NAME? I thought the session and session_id
>>> are for a particular user. If multiple usernames are possible, if we want
>>> to terminate a session, how to achieve that?
>>>
>>  In same browser session for two service providers if authentication
>> steps are different for an example service provider-1 has basic
>> authenticator authenticated with local username 'gayan' and for service
>> provider-2 user authenticated to Facebook federated authenticator with
>> username gayan_em...@gmail.com. Now we have two usernames 'gayan', '
>> gayan_em...@gmail.com' for same SESSION_ID. If we kill the SESSION of
>> 'gayan' it will kill the session of 'gayan_em...@gmail.com' as well. As
>> an improvement we can group USER_NAMEs associate with particular
>> SESSION_ID.
>>
>>>
>>>
>>>

>
>
>>
>> );
>>
>> According to latest implementation of session data persistence, we
>> can consider particular SESSION ID is active if last record (sorted by 
>> time
>> descending order) for given SESSION ID is "STORE" operation. If there are
>> two store operations to IDN_AUTH_SESSION_STORE table there is a problem 
>> of
>> duplicating data in IDN_USER_SESSION_DATA. We need to find a way to 
>> handle
>> this situation.
>>
>> 1. Listing active session list for given user
>>
>> In back-end distinguish sessions will be identified by using
>> SESSION_ID but in front-end we cannot display SESSION_ID. In front-end
>> unique sessions will be displayed according to User-Agent.
>>
>> 2. Listing users who have active sessions
>>
>> Listing users who have at least one active session will be
>> challenging. Since IDN_AUTH_SESSION_STORE table is HUGE in a production
>> system, and doing a JOIN operation with it would be costly.
>>
>> The username in the USER_SESSION_DATA is picked from the
>> authenticated user attribute available in the session context. This
>> attribute is set after all processing done in the SequenceHandler hence 
>> the
>> authenticated user here actually subject identifier, rather than a real
>> username.
>>
>> Hence the username in the USER_SESSION_DATA table can be one of
>> following,
>> i. A Local User : who use the actual username as the subject
>> identifier
>> ii. A Local User : who use a claim as the subject identifier
>> iii. A Federated User : who use federated subject or a claim
>>
>> Only in first scenario, it can find proper user store d

[Architecture] [Dev] WSO2 Identity Server 5.3.0 Milestone 3 Released..!!

[Thanuja Jayasinghe]

*WSO2 Identity Server 5.3.0 Milestone 3 Released..!!*


The WSO2 Identity Server team is pleased to announce the 3rd Milestone of
WSO2 Identity Server 5.3.0. You can download this distribution from
https://github.com/wso2/product-is/releases/tag/v5.3.0-m3

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

   - [IDENTITY-2972 ] -
   Improvements to Identity Management Feature
   - [IDENTITY-3486 ] - New
   claim management feature
   - [IDENTITY-4686 ] - Consume
   the new Rest APIs in IS 5.3.0 for Identity Management scenarios in IS user
   portal
   - [IDENTITY-4756 ] -
   Implement User Self Registration Rest APIs
   - [IDENTITY-4795 ] -
   Improvements in handling incorrect login attempts

Task

   - [IDENTITY-4691 ] -
   Removing jars/wars from features in the pack
   - [IDENTITY-4692 ] - Reduce
   account-recovery webapp size

Sub-task

   - [IDENTITY-2087 ] -
   Password History
   - [IDENTITY-2979 ] - Provide
   a REST endpoint that for Identity Management operations
   - [IDENTITY-3111 ] - Resend
   email for Self Sign-Up - REST API
   - [IDENTITY-3591 ] - User
   challenge question internationalization
   - [IDENTITY-4755 ] - Block
   brute force attacks on password resets



*How To Contribute*
Your feedback are most welcome! Mailing ListsJoin our mailing list and
correspond with the developers directly.

   - Developer List : d...@wso2.org | Subscribe  | Mail
   Archive 
   - User forum : StackOverflow
   

Reporting Issues
We encourage you to report issues, improvements and feature requests
regarding WSO2 Identity Server through public WSO2 Identity Server JIRA
https://wso2.org/jira/browse/IDENTITY


~ The WSO2 Identity Server Team ~

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

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

[Thanuja Jayasinghe]

Hi Farasath,

On Tue, Jun 21, 2016 at 2:57 AM, Farasath Ahamed  wrote:

> 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 are we going to keep track of this "period of time" after an account
> is locked?
>

We calculate unlock time as current timestamp + locked time * 60 * 1000.
After that time, a user can try to reset the password, as in a normal flow.


>
>
>> *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.
>>
>>
>> *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.
>>
>> 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
>>
>>
> Thanks,
> Farasath.
>



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

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

[Thanuja Jayasinghe]

On Mon, Jun 20, 2016 at 7:55 PM, Thanuja Jayasinghe 
wrote:

> Hi Darshana,
>
> On Mon, Jun 20, 2016 at 6:54 PM, Darshana Gunawardana 
> wrote:
>
>> 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.
>>>
>>>
>>> *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.
>>>
>>
>> I assume this new connector will be much similar to "
>> SSOLoginReCaptchaConnector" which is discussed in [1], rather than
>> depending on the "failedLoginAttempts" claim, the new connector will
>> depends on new "failedPasswordResetAttempts" claim.
>>
>
> Yes. They will share a similar design.
>
>
>>
>> *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.
>>>
>>
>> Are you referring locking the password recovery flow? What would be the
>> impact of locking the "password recovery flow" to the "login flow"?
>>
>
> Account lock from any flow (either password recovery flow or login flow)
> will consider as an account locked situation for the user.
>
>
>>
>> Going through supported password recovery flows listed in [2],
>> > Recover with Notification : Has less risk on brute force attacks
>>
> > Recover with Secret Questions (one question at a time) : Has moderate
>> risk on brute force attacks
>> > Recover with Secret Questions (multiple questions at a time) : Has
>> higher risk on brute force attacks
>>
>
>> Considering above, it's better to have this feature enabled by default if
>> the password recovery is enabled.
>>
>
> +1 . We planning to apply these security enhancements only to 'Recover
> with Secret Questions' flows due the less risk in 'Recover with
> Notification' flow.
>
>
>> [1] "[Architecture][IS] Support for Google reCaptha"
>> [2] "Identity Management Recovery API improvements"
>>
>> Thanks,
>> Darshana
>>
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: darsh...@wso2.com *
>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Thanuja Lakmal*
> Senior Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891 +94758009992
>



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

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

[Thanuja Jayasinghe]

Hi Darshana,

On Mon, Jun 20, 2016 at 6:54 PM, Darshana Gunawardana 
wrote:

> 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.
>>
>>
>> *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.
>>
>
> I assume this new connector will be much similar to "
> SSOLoginReCaptchaConnector" which is discussed in [1], rather than
> depending on the "failedLoginAttempts" claim, the new connector will
> depends on new "failedPasswordResetAttempts" claim.
>

Yes. They will share a similar design.


>
> *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.
>>
>
> Are you referring locking the password recovery flow? What would be the
> impact of locking the "password recovery flow" to the "login flow"?
>

Account lock from any flow (either from "password recovery flow" to the
"login flow") will consider as an account locked situation for the user.


>
> Going through supported password recovery flows listed in [2],
> > Recover with Notification : Has less risk on brute force attacks
>
> Recover with Secret Questions (one question at a time) : Has moderate
> risk on brute force attacks
> > Recover with Secret Questions (multiple questions at a time) : Has
> higher risk on brute force attacks
>

> Considering above, it's better to have this feature enabled by default if
> the password recovery is enabled.
>

+1 . We planning to apply these security enhancements only to 'Recover with
Secret Questions' flows due the less risk in 'Recover with Notification'
flow.


> [1] "[Architecture][IS] Support for Google reCaptha"
> [2] "Identity Management Recovery API improvements"
>
> Thanks,
> Darshana
>
>>
>> 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
>>
>>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


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

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

[Thanuja Jayasinghe]

Hi Isura,

On Mon, Jun 20, 2016 at 5:54 PM, Isura Karunaratne  wrote:

> 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?
>
>
Yes, we are planning to use the same configuration used in "account lock
with invalid credentials". Because we can consider this is a possible way
for a user account get locked.


> 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
>
>
Thanks,

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

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

[Thanuja Jayasinghe]

Hi Pushpalanka/Isura,


On Mon, Jun 20, 2016 at 4:50 PM, Pushpalanka Jayawardhana 
wrote:

> Hi Isura,
>
> On Mon, Jun 20, 2016 at 10:52 AM, Isura Karunaratne 
> 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.
>>
>>
>> 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?
>>
> In the given table schema we may need to pay special attention to handle
> user_domain, as secondary user store domain can be changed. Ideally we
> should incorporate a *unique user store domain id* than using user domain
> here.
>

We already have a listener to handle user store domains related operations
called 'AbstractUserStoreConfigListener'. This listener provides "
onUserStoreNamePreUpdate" and "onUserStorePreDelete" methods, which we can
use here to modify "idn_password_history_data" table accordingly.  Also
these methods work with user store domain name.
You can refer [1] for such implementation.


>
>>
>> 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
>>
>>
>
>
> --
> Pushpalanka.
> --
> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
> Mobile: +94779716248
> Blog: pushpalankajaya.blogspot.com/ | LinkedIn:
> lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
[1] -
https://github.com/wso2-extensions/identity-user-account-association/blob/master/components/org.wso2.carbon.identity.user.account.association/src/main/java/org/wso2/carbon/identity/user/account/association/internal/UserStoreConfigListenerImpl.java

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

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

[Thanuja Jayasinghe]

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.


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

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

[Architecture] [Dev] WSO2 Identity Server 5.3.0 Milestone 2 Released..!!

[Thanuja Jayasinghe]

*WSO2 Identity Server 5.3.0 Milestone 2 Released..!!*


The WSO2 Identity Server team is pleased to announce the 2nd Milestone of
WSO2 Identity Server 5.3.0. You can download this distribution from
https://github.com/wso2/product-is/releases/tag/v5.3.0-m2.

Following list contains all features, improvements and bug fixes available
with this milestone.
Improvement

   - [IDENTITY-4686 ] - Rest
   API for user information recovery scenarios in IS user portal

New Feature

   - [IDENTITY-1916 ] - Support
   for OpenID Connect Dynamic Client Registration 1.0
   - [IDENTITY-3504 ] - IWA
   authentication with WSO2 IS on Linux and external Kerberos/NTLM Server
   - [IDENTITY-4284 ] - RFC
   7662 – Token Introspection
   - [IDENTITY-4687 ] -
   Revocation/Regeneration client secret in OAuth 2.0
   - [IDENTITY-4688 ] - Email
   confirmation scenarios

Sub-task

   - [IDENTITY-2979 ] - Provide
   a REST endpoint that for Identity Management operations
   - [IDENTITY-3300 ] - WSO2
   dashboard support user information recovery
   - [IDENTITY-3606 ] -
   Integrate an enhanced captcha library




*How To Contribute*
Your feedback are most welcome! Mailing ListsJoin our mailing list and
correspond with the developers directly.

   - Developer List : d...@wso2.org | Subscribe  | Mail
   Archive 
   - User forum : StackOverflow
   

Reporting Issues
We encourage you to report issues, improvements and feature requests
regarding WSO2 Identity Server through public WSO2 Identity Server JIRA
https://wso2.org/jira/browse/IDENTITY


~ The WSO2 Identity Server Team ~


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

Re: [Architecture] [IS] Support for Google reCaptha

[Thanuja Jayasinghe]

@Omindu

We have generated the key pair providing 'localhost' as the domain name and
we are going to ship this key pair OOTB with the default pack. So any user
can use this key pair for testing.
If they want to configure it for different domain name, they have to
generate a new key pair for that domain.

@Harsha

reCaptcha requires internet connection, since the user validation depend on
communication between Google.

But we will make the filter more generic, so that we can add CAPTCHA as a
connector.

Thanks,

On Wed, Jun 8, 2016 at 1:44 AM, Harsha Thirimanna  wrote:

> Any plan to support *CAPTCHA *in IS without having internet connection ?
> Because previous version of *CAPTCHA* is OOB service and now we are going
> to use google service. Do we have way to install google service plugin or
> something in offline  within product ?
>
>
> *Harsha Thirimanna*
> Associate Tech Lead; WSO2, Inc.; http://wso2.com
> * <http://www.apache.org/>*
> *email: **hars...@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 Wed, Jun 8, 2016 at 1:38 AM, Omindu Rathnaweera 
> wrote:
>
>> First we need to register at [2] and create an API key pair for the
>>> required domain.
>>
>>
>> Should a product user generate their own key pair and configure the
>> product prior to using reCaptcha ?
>>
>> Regards,
>> Omindu.
>>
>>
>> On Tue, Jun 7, 2016 at 11:33 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm working on $subject.
>>>
>>> *Why reCaptcha?*
>>>
>>> *"reCAPTCHA is a free service that protects your website from spam and
>>> abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive
>>> CAPTCHAs to keep automated software from engaging in abusive activities on
>>> your site. It does this while letting your valid users pass through with
>>> ease." -Google[1]*
>>>
>>>
>>> *How does reCaptcha works?*
>>>
>>> First we need to register at [2] and create an API key pair for the
>>> required domain.  The key pair consists of a site key and secret. The site
>>> key used when we display reCaptcha widget on a page. After verification,
>>> new parameter called 'g-recaptcha-response' will be available in the
>>> form which user submits. From the server side we can verify that reCaptcha
>>> response calling the Google API with the secret key.
>>>
>>>
>>> *Where we're going to use reCaptcha?*
>>>
>>> Basically any place which can be vulnerable to Bots attack,
>>>
>>>1. SSO login flow
>>>2. User recovery flows
>>>3. User registration flow
>>>
>>>
>>> *Implementation*
>>>
>>> Conditions to enable reCaptcha is different from one scenario to
>>> another. As an example user registration may enable reCaptcha by default,
>>> but SSO login page may enable it after n failed attempts from a single
>>> user. Also reCaptcha requirements may be different from one tenant to
>>> another.
>>>
>>> So we have introduced filter called "ReCaptchaFilter" to intercept
>>> requests and pass them to a reCaptcha connector which can handle a
>>> particular scenario. Connector will provide following information to the
>>> filter,
>>>
>>>- Whether the connector can handle the request
>>>- Priority of the connector
>>>- Whether the reCapatha verification is needed for the current
>>>request
>>>- Whether that attempt is a successful or not
>>>
>>> Based on above information filter will select a connector which can
>>> handle the incoming request and will validate reCaptcha if needed.
>>>
>>> Also to keep this in a state less manner, IS will do following,
>>>
>>>- Will evaluate the need for reCaptcha at the server side
>>>- Will inform and provide necessary data to the pages if server is
>>>expecting reCaptha validation
>>>
>>>
>>> *OOTB Connectors*
>>>
>>> IS will provide two reCpatcha connectors OOTB as "
>>> SSOLoginReCaptchaConnector" and "PathBasedReCaptchaConnector", which
>>> imple

[Architecture] [IS] Support for Google reCaptha

[Thanuja Jayasinghe]

Hi All,

I'm working on $subject.

*Why reCaptcha?*

*"reCAPTCHA is a free service that protects your website from spam and
abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive
CAPTCHAs to keep automated software from engaging in abusive activities on
your site. It does this while letting your valid users pass through with
ease." -Google[1]*


*How does reCaptcha works?*

First we need to register at [2] and create an API key pair for the
required domain.  The key pair consists of a site key and secret. The site
key used when we display reCaptcha widget on a page. After verification,
new parameter called 'g-recaptcha-response' will be available in the form
which user submits. From the server side we can verify that reCaptcha
response calling the Google API with the secret key.


*Where we're going to use reCaptcha?*

Basically any place which can be vulnerable to Bots attack,

   1. SSO login flow
   2. User recovery flows
   3. User registration flow


*Implementation*

Conditions to enable reCaptcha is different from one scenario to another.
As an example user registration may enable reCaptcha by default, but SSO
login page may enable it after n failed attempts from a single user. Also
reCaptcha requirements may be different from one tenant to another.

So we have introduced filter called "ReCaptchaFilter" to intercept requests
and pass them to a reCaptcha connector which can handle a particular
scenario. Connector will provide following information to the filter,

   - Whether the connector can handle the request
   - Priority of the connector
   - Whether the reCapatha verification is needed for the current request
   - Whether that attempt is a successful or not

Based on above information filter will select a connector which can handle
the incoming request and will validate reCaptcha if needed.

Also to keep this in a state less manner, IS will do following,

   - Will evaluate the need for reCaptcha at the server side
   - Will inform and provide necessary data to the pages if server is
   expecting reCaptha validation


*OOTB Connectors*

IS will provide two reCpatcha connectors OOTB as "SSOLoginReCaptchaConnector"
and "PathBasedReCaptchaConnector", which implement "ReCaptchaConnector"
interface. These connectors also implement "IdentityGovernanceConnector" to
enable UI based configuration management.

SSOLoginReCaptchaConnector - Can enable reCaptcha after n number of failed
attempts form a single user. This connector does not depend on the user
agent and will take the sum of failed attempts from any agent.
PathBasedReCaptchaConnector - Can validate reCaptcha for a request path.
This will always validate reCaptcha for a given request path.


Appreciate your input.

[1] - https://developers.google.com/recaptcha/intro
[2] - https://www.google.com/recaptcha/admin

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

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

[Thanuja Jayasinghe]

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  wrote:

> Hi,
>
> On Tue, Jun 7, 2016 at 10:47 AM, Omindu Rathnaweera 
> 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 
>> 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 
>>> wrote:
>>>
 Hi Malithi,

 These steps seem to be ok. However we are going to move from KAPCHA to
 google reCaptcha in IS 5.3.0 and this captcha implementation is decoupled
 with each flow you mentioned. So, in new implementation captcha validation
 will happen before invoking to the backend APIs.

 In "security questions based password recovery flow", we are going to
 add a new parameter to parameterize the minimum number of questions that
 user should be answered to recover the password. In the previous releases
 (IS 5, IS5.1.0) this is an application side configuration and it was not a
 server side configuration. With IS 5.3.0 onwards tenant admin can define
 the minimum number of questions that user should be answered to recover the
 password.

 Thanks
 Isura



 On Fri, Apr 29, 2016 at 11:40 AM, Malithi Edirisinghe <
 malit...@wso2.com> wrote:

> Hi All,
>
> We are working on $subject.
>
> So with this, we will be supporting below options in the login page of
> the end user dashboard in IS.
>
>1. Forgot Password (Password Recovery)
>2. Forgot Username (Username Recovery)
>3. Create an account (Self Signup)
>
> Below I have listed the user stories that we identified, to support
> each option above.
>
> *Password Recovery*
>
> With the existing information recovery service implementation we can
> support two options.
> Visibility of each option would be decided on the availability of
> required configurations and required user information.
>
>- Password recovery with an email notification (Email transport
>configuration are required and the user should have a valid email 
> address)
>- Password recovery with security questions (User should have
>preconfigured security questions)
>
> *User story for password recovery with email notification*
>
>1. User views a generated captcha
>2. User enters the captcha answer and submit
>3. Server verifies the captcha answer and sends an email
>notification with the confirmation code
>4. User clicks on the received confirmation url
>5. User views a generated captch

[Architecture] WSO2 Carbon Security CAAS 1.0.0-M1 Released

[Thanuja Jayasinghe]

*WSO2 Carbon Security CAAS 1.0.0-M1 Released*

The Identity Server team is pleased to announce the release of Carbon Security
CAAS 1.0.0-M1. It is now available to download from here
.

*Features*

*https://wso2.org/jira/issues/?filter=13052
*

*Installing as a Carbon Feature*

You may install carbon-security-caas feature to your product with:


  org.wso2.carbon.security.caas
  org.wso2.carbon.security.caas.feature
  1.0.0-m1
  zip


*How to Contribute*

   - WSO2 Carbon Security CAAS code is hosted in github.
   - The Git repository is *https://github.com/wso2/carbon-security
   *
   - Carbon Security CAAS 1.0.0-m1 release tag is
*https://github.com/wso2/carbon-security/releases/tag/v1.0.0-m1
   *
   - Please report issues at Carbon Security Jira,
*https://wso2.org/jira/browse/CSECURITY
   *


*Contact Us *

​WSO2 Carbon developers​ can be contacted via following mailing lists:

   - WSO2 Developers List: d...@wso2.org
   - WSO2 Architecture List: architecture@wso2.org


​Thank you for your interest in WSO2 Carbon Security CAAS​.

Best Regards
Identity Server Team

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

[Architecture] SAML2 Toolkit for IS

[Thanuja Jayasinghe]

Hi all,


I'm currently developing $subject which will ease the SAML2 configuration
process in IS. This toolkit consist of two parts,

   1.

   SAML2 Request Validator
   2.

   SAML2 Response Builder


*SAML2 Request Validator*

Using this component users can validate Service Provider(SP) initiated
SAML2 AuthnRequest.

For the validation process following information are required,

   -

   SAML2 AuthnRequest - User needs to provide
   -

   Request Binding - User needs to provide
   -

   SAML2 Web SSO Configuration - As Issuer value comes with request, this
   will be selected automatically

After the validation results will be displayed as steps indicating request
has passed or failed that step. Then the user can adjust the configuration
accordingly.





*SAML2 Response Builder*

Using this component user can generate a SAML2 response for selected SAML2
Web SSO configuration. To generate the response following information are
required,

   -

   SAML2 Web SSO Configuration - User need to provide
   -

   User Name - User need to provide

Using this information response builder will generate the response and will
be represented to the user in both XML and encoded string format. Then user
can use this encoded response to do the validations in SP side.






Thanks,
Thanuja.

-- 
*Thanuja Lakmal*
Software Engineer
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