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