On Tue, Nov 22, 2016 at 11:47 AM, Johann Nallathamby <joh...@wso2.com> wrote:
> 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. > Correction: IMO users and groups have circles, they are groups and hierarchical groups. Also we have another circle of configuration in C5, i.e. "User Domain". Which is a circle of credential/identity store connectors. > > 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>* > -- 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
