Hi Hasanthi,
On Tue, Jan 23, 2018 at 9:53 AM, Hasanthi Purnima Dissanayake <
[email protected]> wrote:
> Hi Johann,
>>
>> Hi All,
>>>
>>>
>>> In this effort we are storing the processed claims from the request
>>> object [1] against the code or the access token. The persistence of JWT
>>> will happen when the response comes to the authorization endpoint.
>>>
>>> 1.
>>>
>>> Authorization request is sent to the authz EP with the request
>>> object. We are validating the request object in this point.
>>> 2.
>>>
>>> Redirecting to the login page. So in the login page the request
>>> object is visible as a query parameter in the browser url.
>>> 3.
>>>
>>> Redirecting to the consent page. In the consent page also the
>>> request object is visible as a query param in the browser url.
>>>
>>> Problem :
>>>
>>> So if someone rewrite the url in the middle and change the JWT we are
>>> persisting the modified JWT which is wrong. So the JWT is open for the
>>> middle man attack.
>>>
>>> As a solution we thought of introducing a table schema as follows to
>>> store the request object.
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_OIDC_CODE_TOKEN (
>>>
>>> ID INTEGER NOT NULL AUTO_INCREMENT,
>>>
>>> CONSUMER_KEY_ID INTEGER ,
>>>
>>> CODE_ID VARCHAR(512) ,
>>>
>>> TOKEN_ID VARCHAR(512) ,
>>>
>>> SESSION_ID INTEGER,
>>>
>>> PRIMARY KEY (ID),
>>>
>>> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES IDN_OAUTH_CONSUMER_APPS(ID) ON
>>> DELETE CASCADE,
>>>
>>> FOREIGN KEY (TOKEN_ID) REFERENCES IDN_OAUTH2_ACCESS_TOKEN(TOKEN_ID) ON
>>> DELETE CASCADE,
>>>
>>> FOREIGN KEY (CODE_ID) REFERENCES IDN_OAUTH2_AUTHORIZATION_CODE(CODE_ID)
>>> ON DELETE CASCADE);
>>>
>>
>> Why do we need a new table here? We already have this relationship
>> between authz_code and access_token in IDN_OAUTH2_AUTHORIZATION_CODE table
>> right? If you want to capture the session data key can't you add it as a
>> column to this table? Why are we instead duplicating 3 fields that are
>> already captured in a different table?
>>
>
> Thanks for bringing this up. We will consider this option.
>
+1
>
>
>>
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_OIDC_REQ_OBJECT_CLAIMS (
>>>
>>> ID INTEGER NOT NULL AUTO_INCREMENT,
>>>
>>> CLAIM_ATTRIBUTE VARCHAR(255) ,
>>>
>>> ESSENTIAL BOOLEAN ,
>>>
>>> VALUE VARCHAR(512) ,
>>>
>>> IS_USERINFO BOOLEAN,
>>>
>>> SESSION_ID INTEGER,
>>>
>>> PRIMARY KEY (ID);
>>>
>>
>> I didn't get why we need to store the requested claims. Can you briefly
>> explain the importance of storing them?
>>
>
> Request object is associated with the OIDC authorization request. So we
> need to return claims from id_token and user_info_endpoint based on the
> requested claims declared in the request object on a token endpoint
> invocation or a user info endpoint invocation. So there should be a way to
> store the processed request object once the authrization request happens.
>
Got it.
>
>
>>
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_OIDC_REQ_OBJECT_CLAIM_VALUES (
>>>
>>> ID INTEGER NOT NULL AUTO_INCREMENT,
>>>
>>> REQ_OBJECT_CLAIMS_ID INTEGER ,
>>>
>>> VALUES VARCHAR(255) ,
>>>
>>> PRIMARY KEY (ID),
>>>
>>> FOREIGN KEY (REQ_OBJECT_CLAIMS_ID) REFERENCES
>>> IDN_OIDC_REQ_OBJECT_CLAIMS(ID) ON DELETE CASCADE);
>>>
>>
>> What is stored in VALUES column?
>>
>>
> If we consider a decoded request object as follows,
>
> {
> "iss": "s6BhdRkqt3",
> "aud": "https://server.example.com";,
> "response_type": "code id_token",
> "client_id": "s6BhdRkqt3",
> "redirect_uri": "https://client.example.org/cb";,
> "scope": "openid",
> "state": "af0ifjsldkj",
> "nonce": "n-0S6_WzA2Mj",
> "max_age": 86400,
> "claims":
> {
> "userinfo":
> {
> "given_name": {"essential": true},
> "nickname": null,
> "email": {"essential": true},
> "email_verified": {"essential": true},
> "picture": null
> },
> "id_token":
> {
> "gender": null,
> "birthdate": {"essential": true},
> "acr": {"values": ["urn:mace:incommon:iap:silver"]}
> }
> }
> }
>
>
> As an example if we consider the 'acr' claim it can contain set of values
> for values : member. So it requests that the claim to be returned with one
> of the defined set of values. So in the 'values' column it will store the
> array values one by one in rows.
>
So it's the way you are storing multi valued attributes. So the VALUE
column of the IDN_OIDC_REQ_OBJECT_CLAIMS will be used to store singular
values? Any reason why we chose to store them in two different places
instead of using the IDN_OIDC_REQ_OBJECT_CLAIM_VALUES table for both?
Regards,
Johann.
> Thanks,
>
>
>
>
> On Tue, Jan 23, 2018 at 9:26 AM, Johann Nallathamby <[email protected]>
> wrote:
>
>> Hi Hasanthi,
>>
>> On Fri, Jan 12, 2018 at 2:48 PM, Hasanthi Purnima Dissanayake <
>> [email protected]> wrote:
>>
>>> Hi All,
>>>
>>>
>>> In this effort we are storing the processed claims from the request
>>> object [1] against the code or the access token. The persistence of JWT
>>> will happen when the response comes to the authorization endpoint.
>>>
>>> 1.
>>>
>>> Authorization request is sent to the authz EP with the request
>>> object. We are validating the request object in this point.
>>> 2.
>>>
>>> Redirecting to the login page. So in the login page the request
>>> object is visible as a query parameter in the browser url.
>>> 3.
>>>
>>> Redirecting to the consent page. In the consent page also the
>>> request object is visible as a query param in the browser url.
>>>
>>> Problem :
>>>
>>> So if someone rewrite the url in the middle and change the JWT we are
>>> persisting the modified JWT which is wrong. So the JWT is open for the
>>> middle man attack.
>>>
>>> As a solution we thought of introducing a table schema as follows to
>>> store the request object.
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_OIDC_CODE_TOKEN (
>>>
>>> ID INTEGER NOT NULL AUTO_INCREMENT,
>>>
>>> CONSUMER_KEY_ID INTEGER ,
>>>
>>> CODE_ID VARCHAR(512) ,
>>>
>>> TOKEN_ID VARCHAR(512) ,
>>>
>>> SESSION_ID INTEGER,
>>>
>>> PRIMARY KEY (ID),
>>>
>>> FOREIGN KEY (CONSUMER_KEY_ID) REFERENCES IDN_OAUTH_CONSUMER_APPS(ID) ON
>>> DELETE CASCADE,
>>>
>>> FOREIGN KEY (TOKEN_ID) REFERENCES IDN_OAUTH2_ACCESS_TOKEN(TOKEN_ID) ON
>>> DELETE CASCADE,
>>>
>>> FOREIGN KEY (CODE_ID) REFERENCES IDN_OAUTH2_AUTHORIZATION_CODE(CODE_ID)
>>> ON DELETE CASCADE);
>>>
>>
>> Why do we need a new table here? We already have this relationship
>> between authz_code and access_token in IDN_OAUTH2_AUTHORIZATION_CODE table
>> right? If you want to capture the session data key can't you add it as a
>> column to this table? Why are we instead duplicating 3 fields that are
>> already captured in a different table?
>>
>>
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_OIDC_REQ_OBJECT_CLAIMS (
>>>
>>> ID INTEGER NOT NULL AUTO_INCREMENT,
>>>
>>> CLAIM_ATTRIBUTE VARCHAR(255) ,
>>>
>>> ESSENTIAL BOOLEAN ,
>>>
>>> VALUE VARCHAR(512) ,
>>>
>>> IS_USERINFO BOOLEAN,
>>>
>>> SESSION_ID INTEGER,
>>>
>>> PRIMARY KEY (ID);
>>>
>>
>> I didn't get why we need to store the requested claims. Can you briefly
>> explain the importance of storing them?
>>
>>
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_OIDC_REQ_OBJECT_CLAIM_VALUES (
>>>
>>> ID INTEGER NOT NULL AUTO_INCREMENT,
>>>
>>> REQ_OBJECT_CLAIMS_ID INTEGER ,
>>>
>>> VALUES VARCHAR(255) ,
>>>
>>> PRIMARY KEY (ID),
>>>
>>> FOREIGN KEY (REQ_OBJECT_CLAIMS_ID) REFERENCES
>>> IDN_OIDC_REQ_OBJECT_CLAIMS(ID) ON DELETE CASCADE);
>>>
>>
>> What is stored in VALUES column?
>>
>> Regards,
>> Johann.
>>
>>
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_OIDC_REQ_OBJECT_SESSION (
>>>
>>> ID INTEGER NOT NULL AUTO_INCREMENT,
>>>
>>> SESSION_DATA_KEY VARCHAR(255),
>>>
>>> PRIMARY KEY (ID);
>>>
>>> As some databases restrict to use table names exceeding the length of 30
>>> I needed to adapt to that when naming the tables.
>>>
>>> So we introduced a new temporary table as IDN_OIDC_REQ_OBJECT_SESSION
>>> to store session data key in a different table.
>>>
>>>
>>> 1.
>>>
>>> When the authorization request comes to the authz endpoint
>>> IDN_OIDC_REQ_OBJECT_SESSION, IDN_OIDC_REQ_OBJECT_CLAIMS and
>>> IDN_OIDC_REQ_OBJECT_CLAIM_VALUES will be filled with the request
>>> object details comes with the original authorization request.
>>> 2.
>>>
>>> After the token or code generation, the corresponding row of the
>>> IDN_OIDC_REQ_OBJECT_SESSION will be removed and the table
>>> IDN_OIDC_CODE_TOKEN will be updated accordingly. So this will allow us to
>>> prevent storing the modified JWT in the db layer.
>>> 3.
>>>
>>> There will be events for token revoke/delete and refresh flows to
>>> update the tables accordingly.
>>>
>>>
>>> Any suggestion or feedback is highly appreciated.
>>>
>>> [1] http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>>>
>>>
>>> --
>>>
>>> Hasanthi Dissanayake
>>>
>>> Senior Software Engineer | WSO2
>>>
>>> E: [email protected]
>>> M :0718407133| http://wso2.com <http://wso2.com/>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile: *+94 77 7776950*
>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>> <http://www.linkedin.com/in/johann-nallathamby>*
>> Medium: *https://medium.com/@johann_nallathamby
>> <https://medium.com/@johann_nallathamby>*
>> Twitter: *@dj_nallaa*
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Hasanthi Dissanayake
>
> Senior Software Engineer | WSO2
>
> E: [email protected]
> M :0718407133| http://wso2.com <http://wso2.com/>
>
--
*Johann Dilantha Nallathamby*
Senior Lead Solutions Engineer
WSO2, Inc.
lean.enterprise.middleware
Mobile: *+94 77 7776950*
LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
<http://www.linkedin.com/in/johann-nallathamby>*
Medium: *https://medium.com/@johann_nallathamby
<https://medium.com/@johann_nallathamby>*
Twitter: *@dj_nallaa*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
