[security-dev] PicketLink IDM API Discussion

Shane Bryzak sbryzak at redhat.com
Mon Oct 8 20:00:33 EDT 2012


I've read through the gist and my comments are inline:


      Developer Side Notes


        <https://gist.github.com/3801805#definitions>Definitions

      *

        What is the difference between getKey() and getId() methods. Can
        we have getId() on the IdentityType ?

        I think we can associate the getKey with the username, for
        example. The getId can be used to let stores identify the user
        internally, like a generated identifier or something.

        Another option is have a getName method on User type and remove
        the getKey. That way we have User.getId and User.getName.
        Remember that other IdentityTypes like Role and Group have a
        getName method.


The getKey() method returns a "globally" unique identifier for that 
identity object.  E.g. for a group called "admins" the key would be 
"GROUP://admins", for a user called jsmith the key would be 
"USER://jsmith".  We need this distinction because permissions can be 
stored against users, groups, or roles using their key and we need a 
reliable way to map this value back to the actual identity object.  The 
getId() method is specific to certain identity types, such as User (in 
which case the id is their user ID, i.e. "jsmith") or Group (where the 
id is the full hierarchy of the group, e.g. 
"/branches/headoffice/managers").


        <https://gist.github.com/3801805#api-design>API Design

      *

        Method IdentityManager.grantRole(role, identityType, group) can
        be split in:

          o IdentityManager.grantRole(role, user)
          o IdentityManager.grantRole(role, group)
          o IdentityManager.addMember(group, identityType)

        Same thing for revokeRole(role, identityType, group),
        hasRole(role, identityType, group)


The role management methods could probably do with some improvement.  
For one thing we don't have explicit support for application roles yet.  
I would suggest something like the following methods:

IdentityManager.grantRole(IdentityType member, Group parent, String 
roleName)
IdentityManager.grantApplicationRole(IdentityType member, String roleName)


      *

        Customization of ldap attributes and db stuff based on
        preexisting DBs and LDAP stores. For databases there is some
        working done in previous versions of PicketLink IDM.

      *

        Serialization of User, Role, Group and Membership types. I think
        is important to make those classes work in a clustered environment.


+1, we should make these interfaces Serializable


      *

        The IdentityManager provides two methods for creating groups
        providing the parent: createGroup(String, Group) and
        createGroup(String, String). Maybe we can have only
        createGroup(String, Group) considering that the parent must be
        always created.


+1, good idea


        <https://gist.github.com/3801805#query-api-design>Query API Design

      * Common interface and base class for UserQuery, RoleQuery,
        GroupQuery and MembershipQuery interfaces/implementations.

+1, all the common stuff should go in a base interface

      * Do we need the *Query.executeQuery(query, range) method ? We
        already have the *Query.executeQuery().

I don't think we need this, the range can be set explicitly on the Query 
object.

      * We can also have a *Query.executeQuery(range) method to
        configure how the query is executed. Instead of always force the
        range argument.
      * The UserQuery interface defines a getName method, but there is
        no such method/property in the User interface. Should we map the
        UserQuery.getName to User.getKey ? This item is related with
        item #1 from the Definitions section.

This should probably be getId() instead.

      * Add support to query users by creation and expiration date.
        There are not methods in the UserQuery to search using these
        attributes.


+1, this is a good idea


        <https://gist.github.com/3801805#messages-and-logging>Messages
        and Logging

      * Better exception hierarchy and handling

+1, we should also define a list of error codes, I'll ask Pete for some 
advice on this.

      * JBoss Logging for messages/exceptions and log messages


My concern here is how we integrate the logging in an SE module with 
CDI.  It would be nice to provide some kind of i18n support, maybe Jason 
would have some suggestions as to how we best achieve this.

      * More logging code (warn, info, error and debug levels)


+1, comprehensive logging is always good


    <https://gist.github.com/3801805#configuration>Configuration

  * Review the builder code ? Use xml or something else ?


    <https://gist.github.com/3801805#documentation>Documentation

  * Start to document what we have so far


    <https://gist.github.com/3801805#feature-proposal>Feature Proposal

  * Password Management API. Support different credentials and
    management features (reset, strength, etc)
  * IDM example appplication
  * REST endpoints for the IdentityManager. As Anil suggested.
  * Event Handling. Which events should be supported (user account
    created/removed/updated/expired, membership created/removed/update,
    etc) ?




On 09/10/12 02:23, Anil Saldhana wrote:
> Hi all,
>
> I am wondering if we can hold a discussion on the IDM API so we lock it
> down in the next couple of weeks.
>
> Recently, Pedro created the following gist page.
> https://gist.github.com/3801805.
>
> Regards,
> Anil
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121009/bdb171cd/attachment-0001.html 


More information about the security-dev mailing list