On Mon, Feb 13, 2017 at 7:33 AM, Sagara Gunathunga <[email protected]> wrote:
> > > On Sun, Feb 12, 2017 at 8:31 AM, Johann Nallathamby <[email protected]> > wrote: > >> >> >> On Fri, Feb 10, 2017 at 1:15 AM, Gayan Gunawardana <[email protected]> >> wrote: >> >>> >>> >>> On Thu, Feb 9, 2017 at 7:43 PM, Omindu Rathnaweera <[email protected]> >>> wrote: >>> >>>> One option would be to introduce a claim property to indicate who can >>>> modify the claims. We can even introduce a similar property to specify who >>>> can read a claim as well. >>>> >>>> Regards, >>>> Omindu >>>> >>>> On Thu, Feb 9, 2017 at 5:39 PM, Isura Karunaratne <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> What is the best way to handle special claims such as last login >>>>> time and last password update time? These claims should >>>>> only be modified by the system. >>>>> >>>>> Ideally, we should not be able to update these claims using an APIs >>>>> such as SCIM. >>>>> >>>> From SCIM user manager level we can filter and remove these claims for >>> Create Update Delete operations. >>> >> >> Totally -1. As Darshana mentioned we should handle these in a centralized >> intercepting layer so that it doesn't get coupled to the various external >> endpoints that we expose. >> > > I also think we should avoid any special claim handling logic at SCIM or > any other feature level, instead those logic need to be handled under > claim-mgt in a generic manner. > > Let me raise a different question, if the system (IS) want to keep IS > runtime specific metadata in a per user basis where we keep them ? ( > assume these metadata are not meaningful outside the IS hence not 1st class > data belong to a particular user) > > Can we use claims to track those system level metadata ? if so how we > differentiate these meta data from other claims ? If we introduce a special > claim dialect called "system dialect" and restrict access to it from > outside, will that solve this issue ? > > Thanks ! > > >> >> SCIM 2.0 in fact defines its own attribute profile in the specification. >> Please check property called "mutability" for each User/Group attribute. >> SCIM 2.0 defines following 4 values by default for it. >> >> "readOnly", "readWrite", "immutable", "writeOnly" >> > This is already handled in SCIM. Suppose if you try to update userName. For userName "mutability" attribute value is "immutable". If you try to modify userName, you will get error response "schemas":"urn:ietf:params:scim:api:messages:2.0:Error","scimType":"mutability" > >> So we can't be doing our own thing here. SCIM 2.0 already defined how to >> handle these kind of claims and we need to be able to support these various >> mutability values from our profile-mgt implementation. >> >> Regards, >> Johann. >> >> -- >> 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 >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sagara Gunathunga > > Associate Director / Architect; WSO2, Inc.; http://wso2.com > V.P Apache Web Services; http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Gayan Gunawardana Software Engineer; WSO2 Inc.; http://wso2.com/ Email: [email protected] Mobile: +94 (71) 8020933
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
