Hi Prabath, Excellent! I think I am with you for the most part of it. But I have problems regarding few points.
On Tue, Jun 21, 2016 at 1:12 PM, Prabath Siriwardana <[email protected]> wrote: > > > On Mon, Jun 20, 2016 at 2:42 PM, Prabath Siriwardana <[email protected]> > wrote: > >> [-strategy@ +architecture@] >> >> Hi Johann, >> >> This captures the high-level overview and looks fine - let me add little >> more to clarify few areas, as per the discussion we had a few weeks back on >> the $subject... >> >> 1. A claim has an identifier.The identifier is unique within a group of >> claims - or a claim dialect. >> >> 2. A claim does not exist by itself - any given claim will belong to a >> claim dialect. We would need to have a root dialect. A claim dialect itself >> has an identifier. >> > I assume by "root" dialect you mean the "wso2" dialect we have now, which we use everywhere in the Carbon console application. I would rather prefer the term "native dialect" which is the only dialect Carbon servers know by default. All other dialects are introduced by the world later on. When we say "root" it assumes a parent-child relationship, which does not exist here, or which you may agree does not exist after reading below comments as well :). >> 3. You define a claim - within a claim dialect. The claim definition >> carries following attributes: >> >> - mapped attribute id (s) by multiple attribute providers. >> - a reference to a policy, which defines who can read/write to the claim >> - under, which criteria the claim is released. >> - criteria to validate the value written to the claim. >> - the type of the claim (String, Integer, Boolean). >> - support multi-values of not. >> > > - whether its required relogin to update/delete claim values > I am hoping all this is only defined for the root/wso2 dialect. Other standard or custom dialects are just way to express the wso2 claim with a different identifier; a mapping defined for a claim in root/wso2 dialect. We are fixing this in IS 5.3.0 so better get it right from now on. > > >> >> 4. Apart from the root dialect, the system can have standard dialects and >> custom dialects. >> > >> 5. There is no semantic difference between a standard dialect and a >> custom dialect. Standard dialects are, OpenID, InfoCard, SCIM. >> >> 6. Like the root dialect, a custom dialect is also a collection of claim >> definitions. And each of these claim definitions can just refer to the root >> claim dialect - and also override 'some' of its attributes. >> > Overriding attributes of the root/wso2 claim dialect in another claim dialect, seems to be making the definition complex/problematic. A dialect is just another identifier for the root/wso2 dialect, as simple as that. I think overriding the root dialect attributes is a another functionality of a "claim profile". So a claim profile has two functions. Earlier I also considered only one, but after your explanation I think there are two. 1. Defines a collection of claim URIs in the root/wso2 dialect. 2. Optionally overrides some of the root/wso2 dialect attributes as long as they are still valid within the confines of the policies that are governing those claims. The rest of the points look absolutely spot on to me. Regards, Johann. > >> 7. Claim dialects are just definitions - do not define their usage. The >> usage of claim dialects is defined in claim profiles (take SAML profile as >> an analogy). >> >> 8. There are multiple usages of claims. Some of them are listed below: >> >> - during SSO share users claims in the SSO response. >> - during federated SSO - request claims from the external identity >> provider. >> - during inbound provisioning >> - during outbound provisioning >> - during just-in-time provisioning >> - during user sign up. >> >> 9. Each usage above is a claim-profile. >> >> 10. There can be a root claim-profile for each of the above scenarios and >> any custom claim profile can extend from them. >> >> 11. Based on the type of the profile, claim-profile adds additional >> attributes to it. For example, the signup profile will have following >> metadata: >> >> - a reference to the claim dialect (which is the root claim dialect) >> - define required claims for the user sign up. >> - define optional claims for the user sign up. >> - define which claims should be verified (for example, email address, >> phone number). >> - override criteria to validate the values written to the claim. >> - default value by claims for optional claims. >> - display order of claims >> - relationships between claims as expressions. For example fullName = >> firstName.concat(' ' + lastName) or emailAddress = firstName.concat('@ >> wso2.com'). >> >> 12. Another example, the JIT provisioning profile will have following >> metadata: >> >> - a reference to the parent profile (which is the root signup profile) >> - override any values - for example, make some optional attributes >> required - and remove the requirement for verification (because we assume >> these are already verified by the identity provider). >> >> 13. There can be saved claim-profiles and dynamic claim profiles. The >> above two examples are for saved claim profiles. A good example for a >> dynamic claim profile is the definition of the required attributes for a >> service provider. You can just select a claim dialect and pick what is >> required and what is not. >> >> 14. Now let's see how the above concept relates to user attributes. A >> user can have multiple named attribute profiles - and pick attributes from >> which profile he/she likes to share with the service provider at the time >> of login. This does not directly relate to the claim profile concept we >> discussed before. >> >> 15. When we support for multiple attribute providers (or stores) - a >> given user's attributes can come from different attribute stores. At the >> moment we assume user attributes are coming only from the user store, the >> user belongs to. How to find the attribute stores for a given user is >> out-of-the-scope of this discussion. Once you find the corresponding user >> store, the claim definitions, will help you to find the mapping >> attributed ids corresponding to that attribute stores. >> > > 16. Need to have the ability to associate workflows with claim value > updates (by claim) > > Thanks & regards, > -Prabath > > >> >> Thanks & regards, >> -Prabath >> >> On Sun, Jun 19, 2016 at 8:49 AM, Johann Nallathamby <[email protected]> >> wrote: >> >>> The user attribute profile management story in IS is weak and not able >>> to cater to requirements from various use cases and protocols. Multiple >>> attribute profiles support is also limited to JDBC user stores. At a very >>> high level I think we need the following design changes to this feature. >>> >>> Definition: >>> *A attribute profile is a collection of claim URIs.* >>> >>> 1. Attribute profile should not have anything to do with the attribute >>> mapping with the underlying user store. Creation of a attribute profile >>> would mean aggregating a set of claim URIs. >>> >>> 2. Some of the metadata we currently define against claims are in fact >>> metadata of a attribute profile. >>> E.g. >>> Display Order - when showing a input form to fill the profile values the >>> order in which the claims are displayed >>> Supported By Default - whether the claim should be shown as part of the >>> form to the user. If 'false' it could mean that the value for this claim >>> may be filled in by the client application or some extension in the IDP. >>> Required - if the claim is mandatory to be filled as part of saving the >>> attribute profile. Currently this validation is done only when updating a >>> user attribute profile, not when adding a user. I think its simply because >>> we have two API methods to do this and we validate only in one. Ideally if >>> 'Required' attribute is enabled we shouldn't be able to even create a user >>> without filling in the value for the attribute profile. >>> >>> These are the current metadata which I feel is incorrectly called claim >>> metadata. There can be more attribute profile metadata in future. We may >>> need to support custom metadata that are required for certain protocols. >>> >>> The remaining metadata currently are, Description, Regular Expression >>> and Read-only which are suitable to be claim metadata. >>> >>> 3. User Attribute Profile / Persona >>> End user of IS should be able to define multiple attribute profiles for >>> himself using the end user portal. >>> In *user-centric* identity it is important that the user is able to >>> define different *personas* for his user account and be able to manage >>> them, control which persona he shares with service providers and revoke >>> access from a service provider to a persona at any given time. >>> >>> 4. Application Attribute Profile >>> A service provider will need to define multiple attribute profiles to be >>> used for various use cases such as self sign-up, JIT provisioning, >>> attribute sharing in SAML2 SSO, SAML2 Assertion Query/Request profile, or >>> OpenID Connect or any inbound protocol that supports attribute sharing. >>> This is partially supported now by defining requested claims for an SP >>> only for attribute sharing with inbound authentication protocols, so we >>> have to extend this to support other use cases as well. >>> >>> 5. Automatically match the user's persona that matches the application >>> profile and shortlist and show them to the user for selection in various >>> scenarios to share attributes. >>> E.g. in OpenID Connect we must show a list of personas that matches the >>> requirements of the application profile so the user can easily select which >>> persona he want's to share. >>> >>> 6. IDP Attribute Profile >>> A service provider will need to define multiple attribute profiles to be >>> used for various use cases such as outbound provisioning, Attribute Query >>> sent by IS to an IDP, etc. Again we have a claim configuration section in >>> IDP currently which we may have to extend to support these use cases. >>> >>> 7. Implementation should not have any part in kernel user.core. >>> Implementation should be completely done in carbon-identity. Supporting >>> multiple attribute profiles for a user even is not a platform feature >>> rather an IS feature. >>> >>> Ideas and suggestions are welcome. This is just a very high level idea >>> and I am sure there are more details to be ironed out. >>> >>> -- >>> 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, >> Prabath >> >> Twitter : @prabath >> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >> >> Mobile : +1 650 625 7950 >> >> http://facilelogin.com >> > > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://facilelogin.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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
