Hi all, These are the design decisions taken in database modification discussion.
*In IS Point of View,* - When a new XACML policy is being added, user can define, for which SP-IDP combination the XACML policy is valid. (We can define valid policy SP-IDP combinations in the "target" tag in policy. eg : <Target ValidSpIdpId="SpId_IdpId"> - SP can be created with or without authorization policy. - When listing down the federated authenticators of each SP, user can decide whether the authorization policy should or shouldn't be set to the SP. - Only XACML type authorization policies can be added. - SP_FEDERATED_IDP table should store whether authorization policy is added or not. Therefore SP_FEDERATED_IDP table structure should be updated as below. COLUMN NAME DATA TYPE SP_ID INTEGER TENANT_ID INTEGER IDP_ID INTEGER IS_POLICY_ADDED CHAR(1) - Each SP-IDP combination can have multiple policies. - When user authenticates for an SP through an IDP, first check whether 'isPolicyAdded' equals to true or false for that SP-IDP combination. - If true, then a XACML request should be sent to the XACML engine with the IDP properties and SpId_IdpID. - Then relevant XACML policies are validated against XACML request. Regards, Lakshani On Fri, Sep 25, 2015 at 10:15 AM, Lakshani Gamage <[email protected]> wrote: > > On Thu, Sep 24, 2015 at 4:06 PM, Lakshani Gamage <[email protected]> > wrote: > >> Hi all, >> >> For bulk subscription feature implementation, some database modification >> are required. I have designed the required database modifications. >> >> Two new tables should be added to identity database. >> >> They are, >> >> 1. *AUTHORIZATION_POLICY_TYPE* - contains authorization policy types. >> >> >> table structure >> >> COLUMN NAME >> >> DATA TYPE >> >> POLICY_ID(P.K) >> >> INTEGER (AUTO_INCREMENT) >> >> POLICY_TYPE >> >> VARCHAR(512) >> >> >> >> 2. *SP_AUTHORIZATION_POLICY* - contains policies of SP >> >> There are 2 ways, we can design that table. >> >> >> i. As SP_FEDERATED_IDP table has a composite primary key, both SP_ID and >> IDP_ID should be included to the table.Table structure is shown in below. >> >> >> COLUMN NAME >> >> DATA TYPE >> >> SP_ID >> >> INTEGER >> >> IDP_ID >> >> INTEGER >> >> POLICY_ID >> >> INTEGER >> >> POLICY_VALUE >> >> VARCHAR(512) >> >> >> >> If one SP-IDP combination has more policy values, SP_ID and IDP_ID repeat >> for several time. Therefore, we can reduce data redundancy from 2nd way. >> >> >> >> ii. Federated authenticators(IDP) and service providers are mapped in >> SP_FEDERATED_IDP table. We can add a unique value column to the table as >> 'SP_IDP_MAP_ID' Still that table. >> >> > *Correction: *We can add a unique value column to the table as > 'SP_IDP_MAP_ID'. > > >> Modified database structure for SP_FEDERATED_IDP is shown in below. >> >> >> >> COLUMN NAME >> >> DATA TYPE >> >> SP_ID >> >> INTEGER >> >> TENANT_ID >> >> INTEGER >> >> IDP_ID >> >> INTEGER >> >> SP_IDP_MAP_ID >> >> INTEGER (AUTO_INCREMENT) >> >> >> Then SP_FEDERATED_IDP table should be created as follows. >> >> > *Correction:* Then SP_AUTHORIZATION_POLICY table should be created as > follows. > > >> >> >> COLUMN NAME >> >> DATA TYPE >> >> SP_IDP_MAP_ID >> >> INTEGER >> >> POLICY_ID >> >> INTEGER >> >> POLICY_VALUE >> >> VARCHAR(512) >> >> >> >> Form the best practices, which way is the most suitable? >> Your ideas are highly appreciated. >> >> Thank you, >> Lakshani >> >> On Tue, Sep 22, 2015 at 12:20 PM, Lakshani Gamage <[email protected]> >> wrote: >> >>> Hi all, >>> >>> These are the design decisions taken in architectural discussion. >>> >>> *In IS point of view* >>> >>> - SP can be created with or without authorization policy. >>> - When list down the Federated authenticators of each SP, user can >>> be define the authorization policy for each authenticator. >>> - Authorization policy can be role based, attribute based (claim >>> based) or XACML policy based depending on the IDP. User should able >>> to choose one of them. >>> - There can be already defined roles, claims or XACML policies. >>> - If user selects one of above authorization policy types, >>> available value set should be displayed for the selected authorization >>> policy category. For example, if 'role' is selected, all available >>> roles are list down. Also, user should able to define new XACML >>> policies. >>> >>> *In App Manager view* >>> >>> - SP related policies should be considered only for bulk >>> subscription not for individual subscription. >>> - Bulk subscription can be done in two ways. >>> - Can select IDP only - Acts as Enterprise subscription (All >>> the users in IDP are subscribed to the Application) >>> - Can select IDP and any numbers of authorization policies (All >>> the users belong to the defined authorization policy are >>> subscribe to the Application) >>> >>> Thank you, >>> Lakshani. >>> >>> >>> On Saturday, September 19, 2015, Prabath Siriwardena <[email protected]> >>> wrote: >>> >>>> I guess from the Identity Server's point of view - we should have the >>>> ability to enforce an authorization policy for an identity provider - at >>>> the service provider level.. >>>> >>>> This authorization policy can be a pointer to a XACML policy - and can >>>> be just role based or just attribute based. >>>> >>>> If its XACML based - then from the Advanced Authentication >>>> Configuration (in the SP UI) - under the Identity Provider - we should be >>>> able to link to a XACML policy in the server. >>>> >>>> If its just role based - the UI should list the roles available at the >>>> Identity Provider (picked from the IdP config) and filter out the required >>>> roles for the particular service provider. >>>> >>>> If its attribute based - the UI should list IdP claims available at the >>>> Identity Provider (picked from the IdP config) and specify what are >>>> required / optional and if present what their values should be... >>>> >>>> Thanks & regards, >>>> -Prabath >>>> >>>> >>>> >>>> On Thu, Sep 17, 2015 at 6:01 PM, Lakshani Gamage <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> In App Manager, Users can subscribe in 2 ways. >>>>> >>>>> They are, >>>>> >>>>> 1. *Subscribe to an App *- This is a 'per user per app' subscription. >>>>> For each and every subscription, a database entry is created with user >>>>> name >>>>> and application name (per user per application subscription) >>>>> >>>>> 2. *Enterprise Subscription* - If users with internal/store-admin >>>>> role enabled an enterprise subscription to an app, all the users who are >>>>> authenticated through the added provider can directly enter their >>>>> credentials and access the Web app as they are automatically subscribed to >>>>> the app through enterprise subscription. >>>>> Here, there are no per user per app entries in the database but only per >>>>> SP entries. >>>>> >>>>> For App manager, different kinds of IDPs can be configured as the >>>>> IDP. In those IDPs, users are categorized based on several policies. (Ex: >>>>> WSO2 IS uses 'roles' to categorize users). >>>>> >>>>> In current implementation of enterprise subscription, all the users >>>>> in IDP are subscribed to application without considering the user >>>>> categories. >>>>> >>>>> From the bulk subscription feature, specific user >>>>> category/categories are subscribed to the application. >>>>> >>>>> Thanks, >>>>> -- >>>>> Lakshani Gamage >>>>> >>>>> *Software Engineer* >>>>> Mobile : +94 (0) 71 5478184 <%2B94%20%280%29%20773%20451194> >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Twitter : @prabath >>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>> >>>> Mobile : +1 650 625 7950 >>>> >>>> http://blog.facilelogin.com >>>> http://blog.api-security.org >>>> >>> >> >> >> -- >> Lakshani Gamage >> >> *Software Engineer* >> Mobile : +94 (0) 71 5478184 <%2B94%20%280%29%20773%20451194> >> > > > > -- > Lakshani Gamage > > *Software Engineer* > Mobile : +94 (0) 71 5478184 <%2B94%20%280%29%20773%20451194> > -- Lakshani Gamage *Software Engineer* Mobile : +94 (0) 71 5478184 <%2B94%20%280%29%20773%20451194>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
