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.
>
>>
>> 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.
>
>>
>> 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.
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/>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
