Hi,

With the offline discussions we had we have decided to introduce a new
table to store JWT audiences and any OIDC related properties which will be
introduced in future. The table has the following structure.

Table: IDP_OIDC_PROPERTY

Columns:
ID    int(11) AI PK
TENANT_ID    int(11)
CONSUMER_KEY    varchar(255)
PROPERTY_KEY    varchar(255)
PROPERTY_VALUE    varchar(2047)

Best regards,
Sathya


On Mon, Jun 5, 2017 at 12:05 PM, Danushka Fernando <[email protected]>
wrote:

> I think its something related to OAuth only. So saving in SP properties
> table isn't the most correct solution. AFAIR for the SAML case we have
> saved properties separately with the registry resource. But rather than
> saving this in registry +1 to save in DB.
> And +1 for Option 2. But beware about the data migration as well. So your
> code should handle null or empty values. Probably use the global value in
> that case.
>
> Thanks & Regards
> Danushka Fernando
> Associate Tech Lead
> WSO2 inc. http://wso2.com/
> Mobile : +94716332729 <+94%2071%20633%202729>
>
> On Mon, Jun 5, 2017 at 11:50 AM, Sathya Bandara <[email protected]> wrote:
>
>> Hi,
>>
>> Currently new audience values to JWT id_tokens should be added via
>> identity.xml file and server needs to be restarted. With this approach we
>> cannot control the id_token audience at SP level since it gets applied
>> globally through identity.xml based configuration. In this case, we are not
>> able to override the audience values at SP level if the id_token is to be
>> used as a JWT grant in a specific IDP. As a solution to this we are
>> providing the audience configuration option in UI via SP Oauth config UI
>> [1].
>>
>> The SP Oauth configuration values obtained from the UI are persisted into
>> the DB via *OauthAdminService* using *registerOAuthApplicationData*
>> method. IDN_OAUTH_CONSUMER_APPS table is used to populate Oauth consumer
>> app related data. For storing the audience values we can add another column
>> into this table to keep them as either space or comma separated values as
>> done for the grant_types. However since there can be multiple audience
>> values for a particular id_token we cannot specify a limitation on the
>> column size.
>>
>> I have also considered the following approach.
>> Adding audience values as key-value pairs in SP_INBOUND_AUTH table
>> identified by the oauth app ID.
>> eg: PROP_NAME = 'audience' -> PROP_VALUE = 'https://localhost:9443/oauth2
>> /token'
>>
>> However with application update these values are being deleted by
>> *IdentityApplicationManagementService*'s *updateApplication* method.
>>
>> As a solution to this we could identify following two options:
>>
>> 1. Create a new table to store audience values identified by oauth
>> application's consumer key.
>>
>> 2. Store them as space separated values in IDN_OAUTH_CONSUMER_APPS table
>> by introducing a new column for audiences with above mentioned limitation
>> on adding multiple audiences.
>>
>> Highly appreciate your suggestions on this.
>>
>> [1] https://wso2.org/jira/browse/IDENTITY-5877
>>
>> Best regards,
>> Sathya
>>
>> --
>> Sathya Bandara
>> Software Engineer
>> WSO2 Inc. http://wso2.com
>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
>>
>> <+94%2071%20411%205032>
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to