[Architecture] Self Contained Access Tokens in IS 5.4.0

2017-11-17 Thread Isura Karunaratne 
Hi all,

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

Shall we increase the column size by default?

Thanks
Isura.


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


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


-- 

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

[Architecture] [IS] - ID_Token validation in OIDC Hybrid Flow.

2017-11-17 Thread Hasini Witharana 
Hi all,

In OIDC Hybrid flow there are some validations that need to be done when
two id_tokens are issued. This happens only when response_type is equal to
"code id_token" or "code id_token token".

The specification[1] state that;
1. “iss” and “sub” claims values must be identical in two id_tokens.
2. If either ID Token contains claims about the End-User, any that are
present in both should have the same values in both.
3. All Claims about the Authentication event present in either should be
present in both.

In our current implementation we do not store the id_token value. We store
an access token and put user attributes against that access token in the
cache and build the id_token .If a service provider(SP) configuration such
as subject identifier is changed  that previous cache entry will be removed
from the cache.

So when one id_token is issued and, while the authorization code is not
expired if a SP's subject identifier configuration is changed, the next
id_token's sub value will be changed. and it will be a specification
violation. But an authorization code is only valid for 5 minutes and the
previously explained scenario is very unlikely to happen within 5 minutes.
After a discussion with team members, we decided to skip the "iss"
validation.

[1] - http://openid.net/specs/openid-connect-core-1_0.html

Thanks.

-- 

*Hasini Witharana*
Software Engineering Intern | WSO2


*Email : hasi...@wso2.com *

*Mobile : +94713850143 <+94%2071%20385%200143>[image:
http://wso2.com/signature] *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

2017-11-17 Thread Isura Karunaratne 
On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne  wrote:

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


-- 

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

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

2017-11-17 Thread Johann Nallathamby 
Self contained JWT's may get quite large and if we set it as the default
size in the script, for users who are not using self contained JWT also it
is going to consume large space in the database.

Did we think about storing a hash of the access token?

On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne  wrote:

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


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

2017-11-17 Thread Farasath Ahamed 
On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby  wrote:

> Self contained JWT's may get quite large and if we set it as the default
> size in the script, for users who are not using self contained JWT also it
> is going to consume large space in the database.
>
> Did we think about storing a hash of the access token?
>

As pointed out by Johann JWT can grow large with requested claims etc. so
changing the column size can happen as soon as the JWT exceeds the defined
length,

Therefore, We had few discussions offline on options to resolve this.

1. User a different data type like BLOB/TEXT to store the JWT access token
and store a hash to improve search. In this approach we will avoid the SQL
error, but there will be performance drop for normal UUID based access
tokens.

2. Not store the self contained access token in the database at all[1].
Since by definition the self contained access token has all the necessary
data to validate it we can validate the token on IS during introspection.
Ideally, the idea behind the self contained access token is to avoid
introspection. But if required we can do it using the presented the JWT
itself.(This is how client will validate the access token anyways).
Downfall of this approach is that we cannot revoke the token since we don't
anyway keep any reference to the issued token.

[1] https://www.oauth.com/oauth2-servers/access-tokens/
self-encoded-access-tokens/



Appreciate your thoughts!



>
> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne  wrote:
>
>>
>>
>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne 
>> wrote:
>>
>>> Hi all,
>>>
>>> Currently, ACCESS_TOKEN column length is defined as 512 [1] which is not
>>> enough to store self-contained access token [2].
>>>
>>> Shall we increase the column size by default?
>>>
>>> Thanks
>>> Isura.
>>>
>>>
>>> [1]
>>> CREATE TABLE IF NOT EXISTS IDN_OAUTH2_ACCESS_TOKEN (
>>> TOKEN_ID VARCHAR (255),
>>> ACCESS_TOKEN VARCHAR(512),
>>> REFRESH_TOKEN VARCHAR(512),
>>> CONSUMER_KEY_ID INTEGER,
>>> AUTHZ_USER VARCHAR (100),
>>> TENANT_ID INTEGER,
>>> USER_DOMAIN VARCHAR(50),
>>> USER_TYPE VARCHAR (25),
>>> GRANT_TYPE VARCHAR (50),
>>> TIME_CREATED TIMESTAMP DEFAULT 0,
>>> REFRESH_TOKEN_TIME_CREATED TIMESTAMP DEFAULT 0,
>>> VALIDITY_PERIOD BIGINT,
>>> REFRESH_TOKEN_VALIDITY_PERIOD BIGINT,
>>> TOKEN_SCOPE_HASH VARCHAR(32),
>>> TOKEN_STATE VARCHAR(25) DEFAULT 'ACTIVE',
>>> TOKEN_STATE_ID VARCHAR (128) DEFAULT 'NONE',
>>> SUBJECT_IDENTIFIER VARCHAR(255),
>>> PRIMARY KEY (TOKEN_ID),
>>> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES
>>> IDN_OAUTH_CONSUMER_APPS(ID) ON DELETE CASCADE,
>>> CONSTRAINT CON_APP_KEY UNIQUE (CONSUMER_KEY_ID,AUTHZ_USER,TE
>>> NANT_ID,USER_DOMAIN,USER_TYPE,TOKEN_SCOPE_HASH,
>>>TOKEN_STATE,TOKEN_STATE_ID)
>>>
>>>
>>> [2] https://wso2.org/jira/browse/IDENTITY-6917
>>>
>>>
>>> --
>>>
>>> *Isura Dilhara Karunaratne*
>>> Associate Technical Lead | WSO2
>>> Email: is...@wso2.com
>>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>>> Blog : http://isurad.blogspot.com/
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> *Isura Dilhara Karunaratne*
>> Associate Technical Lead | WSO2
>> Email: is...@wso2.com
>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

2017-11-17 Thread Johann Nallathamby 
Hi Farasath,

On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed  wrote:

>
> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby 
> wrote:
>
>> Self contained JWT's may get quite large and if we set it as the default
>> size in the script, for users who are not using self contained JWT also it
>> is going to consume large space in the database.
>>
>> Did we think about storing a hash of the access token?
>>
>
> As pointed out by Johann JWT can grow large with requested claims etc. so
> changing the column size can happen as soon as the JWT exceeds the defined
> length,
>
> Therefore, We had few discussions offline on options to resolve this.
>
> 1. User a different data type like BLOB/TEXT to store the JWT access token
> and store a hash to improve search. In this approach we will avoid the SQL
> error, but there will be performance drop for normal UUID based access
> tokens.
>

May be we can introduce a config to say whether we need to hash or not.


>
> 2. Not store the self contained access token in the database at all[1].
> Since by definition the self contained access token has all the necessary
> data to validate it we can validate the token on IS during introspection.
> Ideally, the idea behind the self contained access token is to avoid
> introspection. But if required we can do it using the presented the JWT
> itself.(This is how client will validate the access token anyways).
> Downfall of this approach is that we cannot revoke the token since we
> don't anyway keep any reference to the issued token.
>

We can use the "jti" claim of the JWT as the reference and use it to manage
the token in IS.

Regards,
Johann.


>
> [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
> encoded-access-tokens/
> 
>
>
> Appreciate your thoughts!
>
>
>
>>
>> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi all,

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

 Shall we increase the column size by default?

 Thanks
 Isura.


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


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


 --

 *Isura Dilhara Karunaratne*
 Associate Technical Lead | WSO2
 Email: is...@wso2.com
 Mob : +94 772 254 810 <+94%2077%20225%204810>
 Blog : http://isurad.blogspot.com/




>>>
>>>
>>> --
>>>
>>> *Isura Dilhara Karunaratne*
>>> Associate Technical Lead | WSO2
>>> Email: is...@wso2.com
>>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>>> Blog : http://isurad.blogspot.com/
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com *
>>
>
>


-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

2017-11-17 Thread Malithi Edirisinghe 
On Fri, Nov 17, 2017 at 6:12 PM, Johann Nallathamby  wrote:

> Hi Farasath,
>
> On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed 
> wrote:
>
>>
>> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby 
>> wrote:
>>
>>> Self contained JWT's may get quite large and if we set it as the default
>>> size in the script, for users who are not using self contained JWT also it
>>> is going to consume large space in the database.
>>>
>>> Did we think about storing a hash of the access token?
>>>
>>
>> As pointed out by Johann JWT can grow large with requested claims etc. so
>> changing the column size can happen as soon as the JWT exceeds the defined
>> length,
>>
>> Therefore, We had few discussions offline on options to resolve this.
>>
>> 1. User a different data type like BLOB/TEXT to store the JWT access
>> token and store a hash to improve search. In this approach we will avoid
>> the SQL error, but there will be performance drop for normal UUID based
>> access tokens.
>>
>
> May be we can introduce a config to say whether we need to hash or not.
>
>
>>
>> 2. Not store the self contained access token in the database at all[1].
>> Since by definition the self contained access token has all the necessary
>> data to validate it we can validate the token on IS during introspection.
>> Ideally, the idea behind the self contained access token is to avoid
>> introspection. But if required we can do it using the presented the JWT
>> itself.(This is how client will validate the access token anyways).
>> Downfall of this approach is that we cannot revoke the token since we
>> don't anyway keep any reference to the issued token.
>>
>
> We can use the "jti" claim of the JWT as the reference and use it to
> manage the token in IS.
>

So I think you meant that we don't need to persist the self contained
access token at all (even the hash) and use an identifier to reference the
token issued. And that reference will be returned with the JWT as 'jti'
claim.


>
> Regards,
> Johann.
>
>
>>
>> [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
>> encoded-access-tokens/
>> 
>>
>>
>> Appreciate your thoughts!
>>
>>
>>
>>>
>>> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne 
>>> wrote:
>>>


 On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne 
 wrote:

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


 --

 *Isura Dilhara Karunaratne*
 Associate Technical Lead | WSO2
 Email: is...@wso2.com
 Mob : +94 772 254 810 <+94%2077%20225%204810>
 Blog : http://isurad.blogspot.com/




>>>
>>>
>>> --
>>> Thanks & Regards,
>>>
>>> *Johann Dilantha Nallathamby*
>>> Senior Lead Solutions Engineer
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+9476950*
>>> Blog - *http://nallaa.wordpress.com *
>>>
>>
>>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.

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

2017-11-17 Thread Johann Nallathamby 
On Fri, Nov 17, 2017 at 6:39 PM, Malithi Edirisinghe 
wrote:

>
>
> On Fri, Nov 17, 2017 at 6:12 PM, Johann Nallathamby 
> wrote:
>
>> Hi Farasath,
>>
>> On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed 
>> wrote:
>>
>>>
>>> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby 
>>> wrote:
>>>
 Self contained JWT's may get quite large and if we set it as the
 default size in the script, for users who are not using self contained JWT
 also it is going to consume large space in the database.

 Did we think about storing a hash of the access token?

>>>
>>> As pointed out by Johann JWT can grow large with requested claims etc.
>>> so changing the column size can happen as soon as the JWT exceeds the
>>> defined length,
>>>
>>> Therefore, We had few discussions offline on options to resolve this.
>>>
>>> 1. User a different data type like BLOB/TEXT to store the JWT access
>>> token and store a hash to improve search. In this approach we will avoid
>>> the SQL error, but there will be performance drop for normal UUID based
>>> access tokens.
>>>
>>
>> May be we can introduce a config to say whether we need to hash or not.
>>
>>
>>>
>>> 2. Not store the self contained access token in the database at all[1].
>>> Since by definition the self contained access token has all the necessary
>>> data to validate it we can validate the token on IS during introspection.
>>> Ideally, the idea behind the self contained access token is to avoid
>>> introspection. But if required we can do it using the presented the JWT
>>> itself.(This is how client will validate the access token anyways).
>>> Downfall of this approach is that we cannot revoke the token since we
>>> don't anyway keep any reference to the issued token.
>>>
>>
>> We can use the "jti" claim of the JWT as the reference and use it to
>> manage the token in IS.
>>
>
> So I think you meant that we don't need to persist the self contained
> access token at all (even the hash) and use an identifier to reference the
> token issued. And that reference will be returned with the JWT as 'jti'
> claim.
>

Yes


>
>
>>
>> Regards,
>> Johann.
>>
>>
>>>
>>> [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
>>> encoded-access-tokens/
>>> 
>>>
>>>
>>> Appreciate your thoughts!
>>>
>>>
>>>

 On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne 
 wrote:

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


 --
 Thanks & Regards,

 *Johann Dilantha Nallathamby*
 Senior Lead Solutions Engineer
 WSO2, Inc.
 lean.enterprise.middleware

 Mobile - *+9476950*
 Blog - *http://nallaa.wordpress.com

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

2017-11-17 Thread Farasath Ahamed 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 




On Fri, Nov 17, 2017 at 6:48 PM, Johann Nallathamby  wrote:

>
>
> On Fri, Nov 17, 2017 at 6:39 PM, Malithi Edirisinghe 
> wrote:
>
>>
>>
>> On Fri, Nov 17, 2017 at 6:12 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Farasath,
>>>
>>> On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed 
>>> wrote:
>>>

 On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby 
 wrote:

> Self contained JWT's may get quite large and if we set it as the
> default size in the script, for users who are not using self contained JWT
> also it is going to consume large space in the database.
>
> Did we think about storing a hash of the access token?
>

 As pointed out by Johann JWT can grow large with requested claims etc.
 so changing the column size can happen as soon as the JWT exceeds the
 defined length,

 Therefore, We had few discussions offline on options to resolve this.

 1. User a different data type like BLOB/TEXT to store the JWT access
 token and store a hash to improve search. In this approach we will avoid
 the SQL error, but there will be performance drop for normal UUID based
 access tokens.

>>>
>>> May be we can introduce a config to say whether we need to hash or not.
>>>
>>>

 2. Not store the self contained access token in the database at all[1].
 Since by definition the self contained access token has all the necessary
 data to validate it we can validate the token on IS during introspection.
 Ideally, the idea behind the self contained access token is to avoid
 introspection. But if required we can do it using the presented the JWT
 itself.(This is how client will validate the access token anyways).
 Downfall of this approach is that we cannot revoke the token since we
 don't anyway keep any reference to the issued token.

>>>
>>> We can use the "jti" claim of the JWT as the reference and use it to
>>> manage the token in IS.
>>>
>>
>> So I think you meant that we don't need to persist the self contained
>> access token at all (even the hash) and use an identifier to reference the
>> token issued. And that reference will be returned with the JWT as 'jti'
>> claim.
>>
>
> Yes
>

So we can store the jti as the access_token in the IDN_ACCESS_TOKEN table.
Is my understanding correct?


>
>
>>
>>
>>>
>>> Regards,
>>> Johann.
>>>
>>>

 [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
 encoded-access-tokens/
 


 Appreciate your thoughts!



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

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

2017-11-17 Thread Johann Nallathamby 
On Fri, Nov 17, 2017 at 7:08 PM, Farasath Ahamed  wrote:

>
>
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
> On Fri, Nov 17, 2017 at 6:48 PM, Johann Nallathamby 
> wrote:
>
>>
>>
>> On Fri, Nov 17, 2017 at 6:39 PM, Malithi Edirisinghe 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 17, 2017 at 6:12 PM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Farasath,

 On Fri, Nov 17, 2017 at 5:35 PM, Farasath Ahamed 
 wrote:

>
> On Fri, Nov 17, 2017 at 3:23 PM, Johann Nallathamby 
> wrote:
>
>> Self contained JWT's may get quite large and if we set it as the
>> default size in the script, for users who are not using self contained 
>> JWT
>> also it is going to consume large space in the database.
>>
>> Did we think about storing a hash of the access token?
>>
>
> As pointed out by Johann JWT can grow large with requested claims etc.
> so changing the column size can happen as soon as the JWT exceeds the
> defined length,
>
> Therefore, We had few discussions offline on options to resolve this.
>
> 1. User a different data type like BLOB/TEXT to store the JWT access
> token and store a hash to improve search. In this approach we will avoid
> the SQL error, but there will be performance drop for normal UUID based
> access tokens.
>

 May be we can introduce a config to say whether we need to hash or not.


>
> 2. Not store the self contained access token in the database at
> all[1]. Since by definition the self contained access token has all the
> necessary data to validate it we can validate the token on IS during
> introspection. Ideally, the idea behind the self contained access token is
> to avoid introspection. But if required we can do it using the presented
> the JWT itself.(This is how client will validate the access token 
> anyways).
> Downfall of this approach is that we cannot revoke the token since we
> don't anyway keep any reference to the issued token.
>

 We can use the "jti" claim of the JWT as the reference and use it to
 manage the token in IS.

>>>
>>> So I think you meant that we don't need to persist the self contained
>>> access token at all (even the hash) and use an identifier to reference the
>>> token issued. And that reference will be returned with the JWT as 'jti'
>>> claim.
>>>
>>
>> Yes
>>
>
> So we can store the jti as the access_token in the IDN_ACCESS_TOKEN table.
> Is my understanding correct?
>

Yes :)


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

 Regards,
 Johann.


>
> [1] https://www.oauth.com/oauth2-servers/access-tokens/self-
> encoded-access-tokens/
> 
>
>
> Appreciate your thoughts!
>
>
>
>>
>> On Fri, Nov 17, 2017 at 3:06 PM, Isura Karunaratne 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 17, 2017 at 1:35 PM, Isura Karunaratne 
>>> wrote:
>>>
 Hi all,

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

 Shall we increase the column size by default?

 Thanks
 Isura.


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

  TOKEN_STATE,TOKEN_STATE_ID)


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


 --

[Architecture] WSO2 IoT Server 3.1.0-UPDATE6 Released!

2017-11-17 Thread Charitha Goonetilleke 
WSO2 IoT Server 3.1.0 UPDATE 6

We are pleased to announce the latest update to WSO2 IoT Server 3.1.0

WSO2 IoT Server is one of the most adaptive Apache licensed open source IoT
platforms available today. It provides best of breed technologies for
device manufacturers to develop connected products as well as rich
integration and smart analytics capabilities for system integrators to
adopt devices into systems they build.

These capabilities involve device management, smart analytics, API and app
management for devices, transport extensions for MQTT, XMPP and many more.
What's new in WSO2 IoTS 3.1.0 Update 6

New Feature: Expose device management core APIs as siddhi extensions.
Bug Fixes : A list of bug fixes shipped with this release can be found here

Download

You can download WSO2 IoT Server 3.1.0-UPDATE6 from here

.
Documentation

Documentations: WSO2 IoT Server Documentation

Known Issues

The known set of issues in this version can be found here

Engaging with CommunityMailing Lists

Join our mailing list and correspondence with the developers directly.

Developer list: d...@wso2.org | Subscribe
 | Mail Archive

Reporting Issues

We encourage you to report issues, documentation faults and feature
requests regarding WSO2 IoT Server through WSO2 IoT GIT Issues
.
Discussion Forums

We encourage you to use stackoverflow

to
engage with developers as well as other users.

For more information about WSO2 IoT Server, please see
http://wso2.com/products/iot-server or visit the WSO2 Oxygen Tank
 developer portal for additional resources.

Thank you for your interest in WSO2 IoT Server.

*The WSO2 IoT Server Team*

-- 
*Charitha Goonetilleke*
Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 77 751 3669 <%2B94777513669>
Twitter:@CharithaWs , fb: charithag
, linkedin: charithag



___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture