On Mon, Sep 28, 2015 at 12:30 PM, Lakshani Gamage <[email protected]> wrote:
> 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"> > > Is SP-IDP combination a unique combination in all scenarios ? > > - 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> > -- *Rushmin Fernando* *Technical Lead* WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware email : [email protected] mobile : +94772310855
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
