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