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