[Dev] [IAM] JIRA Not Resolved?

[Johann Nallathamby]

As far as I know we do support internationalization of
/accountrecoveryendpoint [1]. However, seems the JIRA is still open for
this [2]. At the same time I couldn't find a JIRA for internationalization
of /dashboard.

[1] https://github.com/wso2/carbon-identity-framework/pull/1566
[2] https://github.com/wso2/product-is/issues/5657

Thanks & Regards,
Johann.

-- 
*Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
WSO2 Inc.
(m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
[image: Signature.jpg]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] 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 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 

[Dev] [IAM] Implementing a unique user identifier in WSO2 Identity Server

[Ashen Weerathunga]

Hi All,

Currently, we consider username of the user as an immutable attribute
across the Identity Server and we do not maintain any other unique user
identifier for all the users apart from the SCIM ID which is only
applicable for SCIM enabled user stores.

So we are in the process of introducing an immutable user identifier that
is unique across the system and maintains a mapping with all the other user
attributes which will enable the following capabilities in the product.

   - *Provide a unique user identifier across the system* - This id will be
   used for new Admin REST APIs, Identify the user internally and the same ID
   will be used as the SCIM ID as well.
   - *Username renaming capability* - The users will be able to change them
   without having any impact on the existing system.
   - *Multi-attribute login capability* - The users will be able to have
   multiple login identifiers such as username, email address, mobile number
   or any other identifier that’s unique across the system as for their
   preference.


For this, we will be introducing a new UserStoreManager interface with the
new APIs and the relevant implementations to work with the unique user ID
as below,
[image: Unique user identifier for IS .jpg]

During discussions we had so far, usercore API implementation and the
impact for other dependant components were discussed in detail under the
following categories,

*New product deployments:*

   - They can directly start using the new functionalities as they are
   enabled by default in the product.

*Existing **product deployments** which does not require new
functionalities:*

   - These types of users should be able to disable new functionalities and
   use the old implementation. A configuration can be used to switch off the
   new functionalities.

*Existing **product deployments** which **require* *new functionalities**:*

   - These users will require a data migration and we need to finalize the
   process.
   - In this scenario, we discussed on supporting existing usercore APIs as
   well in a migrated environment to make sure existing dependent components
   are not breaking. So all the dependent components can be migrated
   eventually to the new usercore APIs which work with the new user ID.
   - New usercore APIs should consider supporting existing event listeners
   for the relevant user operations to maintain backward compatibility.
   - Apart from the above concerns we need to address the performance
   aspect as well.

So in this process, the following dependent components should be migrated
to work with new APIs eventually,

   - Identity framework
   - SCIM implementation
   - Basic authenticator
   - Management console
   - OAuth2 components (Password grant, etc)
   - Any other dependant products/components

We will be having continues discussions on this while doing the
implementation and highly appreciate your feedback as well.

Thanks,
Ashen
-- 
Ashen Weerathunga | Senior Software Engineer | WSO2 Inc.
(m) +94716042995 | (w) +94112145345 | Email: as...@wso2.com

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] 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
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev