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

Reply via email to