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