I think from all the requirements gathered so far I see requirements for 3 different types of Circles. I see Circle as a grouping of entities.
1. Circle of Configuration Applying configuration in bulk fashion to multiple service providers at the same time. I see this requirement only for service providers. I don't think we have this requirement for any other entities in IS such as IdPs, users, groups, roles, permissions, identity stores, claims, policies, etc. because all these entities are configured individually. Most of the common configuration come only when associating these entities with service providers. One of the arguments that came was that we need a concept of circle for users as well. But AFAIU the well established concept of a "Group" in the IAM world, is a kind of circle of users. Counter argument for "Group" was that it is a implementation level construct (generally coming from LDAP world), therefore it is not advisable to rely on that; so we need a higher level construct than "User Group" like "User Circle". But my counter argument for that is that "Group" is a well established circle of users. It doesn't actually refer to LDAP level groups or anything, but is a concept. Even if LDAPs don't support Groups tomorrow we still need the concept of a Group in IAM. I don't see a compelling reason/requirement to introduce a higher level grouping such as "Circle" for users. If needed it can be achieved by combining multiple "Groups" in the multiple IdentityStores. 2. Circle of Sessions As Ishara has already mentioned requirement for this is to maintain an IS logged-in session per group of SPs per user. SSO and SLO will happen only within the group for the user. 3. Circle of Trust This is what most other products out there talk about. And actually it seems like nothing but what we already have in current IS - that is to associate a trusted IDP to an SP and create a circle of trust. Therefore AFAIU new requirements for IS on C5 are the first two. On Wed, Nov 16, 2016 at 12:22 PM, Pushpalanka Jayawardhana <la...@wso2.com> wrote: > Hi All, > > As I could deduce from the discussion so far, we are looking for 2 main > purposes to be achieved with security circles. > > 1. Bulk configuration of service providers > 2. Limiting the session sharing between service providers > > *Bulk configuration of service providers* > This will be beneficial in cases, > > Many service providers are present in the environment while all have > similar configurations to be applied > In updating of service provider configurations which needs same > modification . > > Value addition will be less in below cases, > > Service provider configuration not a frequent operation > Most use cases having ~10 service providers > > If service providers does not share similar configurations > > If we are moving forward with file based configuration of service > providers, bulk configuration/update means file modification applied to > several files. > > > We can loosen the requirement for service providers to have same > configuration, by letting service providers override it as IsharaK > mentioned. Another option is to treat claim config, provisioning config, > authentication flow as different small circles. Depending on the > configuration patterns, we may create new bigger circles using these small > circles. With this granularity re-usability of a one set of configuration > will be high, but only beneficial if there is a big number of service > providers. In this sense IDP can also be treated within a circle. > What you are suggesting is hierarchical circles. Technically it is possible. But we need to evaluate the cost of implementing it and return we get. We have hierarchical groups for C5 which was a critical requirement for many users. I think we need to find valid use cases from past experience and judge if we need hierarchical circles or not. > *Limiting the session sharing between service providers* > Assume a service provider is no allowed to be present in two security > circles as that would violate the session sharing limitation for rest of > the service providers in the related circles. > Let's take 3 service providers A.B and C. > > B needs to share the session with A > > C needs to share the session with A > > But B and C should not share the session. (not transitive) As I > understood so far, this is not possible with security circles. > > Again have you come across requirements like this? AFAIK requirement for session circles come in mutually exclusive form. Generally they don't overlap. But I may be wrong. IS 6.0.0 is not going to be the end. As and when we see new requirements we can improve. We don't need to put everything on our plate until a valid requirement comes along. Regards, Johann. > > Thanks, > Pushpalanka > > On Mon, Nov 7, 2016 at 10:59 AM, Dimuthu Leelarathne <dimut...@wso2.com> > wrote: > >> >> >> On Sun, Oct 16, 2016 at 11:37 AM, Ishara Karunarathna <isha...@wso2.com> >> wrote: >> >>> Hi All, >>> >>> With the current IS implementation We have individual SP configurations >>> and we associate authentication chains, claim, provisioning configurations >>> etc.. to that service provider configuration. >>> As a improvement to this we can group these configurations lets say a >>> security circle. >>> >>> For a security circle [SC]. >>> We can configure set of service providers within a SC. >>> Associate Userstores to that SC >>> Define Authentication chain, Provision config etc.. >>> Configre Administration policies Ex: only users in wso2admin can manage >>> the wso2 security circle. >>> >> >> According to new security model, I hope we can associate admins for SCs >> to achieve the exact Enterprise usecase defined in "[C5 IS] >> Multi-tenancy in C5 based IS". >> >> thanks, >> Dimuthu >> >> >>> Group authorization policies belong to this circle. >>> Once we configure those it will be applicable to all service providers >>> and can override with SP level configurations. >>> We can have different login sessions to each circle. >>> >>> How can we use this. >>> Achieve Enterprise SaaS application use case discussed in [1] >>> No need to configure same configurations in each SP level can inherit >>> from SC configurations. >>> Since we are going with container base Multi tenancy in C5, If a user >>> does not like, that can be handle with this security circle. >>> >>> Thanks, >>> Ishara >>> [1] "[C5 IS] Multi-tenancy in C5 based IS" >>> >>> -- >>> Ishara Karunarathna >>> Associate Technical Lead >>> WSO2 Inc. - lean . enterprise . middleware | wso2.com >>> >>> email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile: >>> +94717996791 >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Director, Solutions Architecture >> >> WSO2, Inc. (http://wso2.com) >> email: dimut...@wso2.com >> Mobile: +94773661935 >> Blog: http://muthulee.blogspot.com >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Pushpalanka. > -- > Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). > Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ > Mobile: +94779716248 > Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p > ushpalanka/ | Twitter: @pushpalanka > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Technical Lead & Product Lead of WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
