1 2 Previous Next 19 Replies Latest reply on Jun 7, 2010 2:57 AM by bdaw Go to original post
      • 15. Re: Seam Security 3.0 and PicketLink
        bdaw

        Shane Bryzak wrote:

         

        One other related feature that I've been toying with is the ability to support scheduling for user enablement and role membership.  It would be really nice if it were possible for example to only enable users between certain times on certain days, or have their role memberships activated in the same way.  Also useful would be account and membership expiry, where an account or a granted role or group membership would expire after so much time.

         

         

        I like the idea but I would keep such features as something optional so maybe some extension point enabling to plug additional logic when memberships or attribute values are resolved? This can be implemented with current attributes and role properties. So simply role would have properties defining when it is valid. Some kind of pluggable "Resolver" with a set of implementations could make sense. I would rather keep this outside of core managers implementations. JIRA: https://jira.jboss.org/browse/PLIDM-16

         

        Shane Bryzak wrote:

         

        I think this is as simple as allowing groups to become members of other groups (I thought PLIDM already supported this though?).  I don't think it calls for yet another interface - surely another method could just be added to RelationshipManager?

         

        ...

         

        I thought that the associateUser() etc methods created a relationship with a type name of "JBOSS_IDENTITY_MEMBERSHIP" - this is the intent of the addUserToGroup() etc methods I listed in IdentityManager.  I'm willing to compromise on this though - after thinking about it some more I think I like the PLIDM method names better, so I'll remove addUserToGroup()/removeUserFromGroup() and replace with associateUser, associateGroup etc, that will bring them more in line.

         

         

         

        My fault. Somehow I missed the addUserToGroup() method from your proposa. Sorry for the confusion.

         

         

        To give some update about IdentityManager discussion we had a short chat on IM with Shane and both agreed that it would be better to keep the implementation in Seam codebase. At the moment we are discussing direct PLIDM API usage in GateIn as well and we are more towards keeping additional GateIn Identity API layer on top of PicketLink IDM. The biggest benefit is to decouple IDM framework lifecycle from its adopters. On the other hand it will give us more freedom and control of how we use it. Also PLIDM API would remain more flexible and complex while Seam and GateIn can shape its APIs in more use case driven way for our users. This will help to keep API not affected with minor requirements from other camps.

         

        The most important thing is to keep compatibility on the core framework usage level so that any SPI implementation or API extension added by GateIn, Seam or others can be reused. Lets keep the discussion about any additional extension points or plugins for 2.x branch that would help with such adoption. This will let us to merge all extensions or different implementations into PLIDM codebase so they can be tested with common testsuite to ensure compatibility. Would be good to create a JIRA for each idea that matters.

        • 16. Re: Seam Security 3.0 and PicketLink
          pmuir

          To give some update about IdentityManager discussion we had a short chat on IM with Shane and both agreed that it would be better to keep the implementation in Seam codebase. At the moment we are discussing direct PLIDM API usage in GateIn as well and we are more towards keeping additional GateIn Identity API layer on top of PicketLink IDM. The biggest benefit is to decouple IDM framework lifecycle from its adopters. On the other hand it will give us more freedom and control of how we use it. Also PLIDM API would remain more flexible and complex while Seam and GateIn can shape its APIs in more use case driven way for our users. This will help to keep API not affected with minor requirements from other camps.

          Guys, we need to take a step back and think for a minute less about us, and more about our users, and how they use our software in their applications. One of the key benefits we can give people is a fully integrated stack with a unified API. Every time we wrap an API, we introduce another API for users to learn, and another barrier to entry for JBoss software. The Java space is splintered enough without us making it worse!

           

          So whilst, yes, wrapping the API does make our lives easier, it makes our users lives harder. And remember there are (hopefully) far more users than developers, so us making the effort to unify the API and synchronize the lifecycle is far more efficient.

           

          I'm not saying we have to have a unified API right now, but we need to aim towards it.

           

          And, honestly, I thought creating a unified approach to IDM across JBoss was a (the?!) key objective of this project...

          • 17. Re: Seam Security 3.0 and PicketLink
            anil.saldhana

            Pete, in the long run, the PicketLink IDM API should be the final identity model api for the projects.  Now if the projects want to have their implementation of the API based on their use cases, then that is fine.  But we need to agree on the API that we deliver as part of this project.

             

            I second your opinion on prohibiting API wrappers.

            • 18. Re: Seam Security 3.0 and PicketLink
              theute

              I think the key objective was to have a common SPI, so you can plug your identity store on any JBoss project. This goal was achieved.

               

              You're right, the other initial idea was also to propose a simple common API and we've tried that road with jBPM. The issue wasn't that it was harder for us but for the users and we wanted to avoid that. We all agree on that.

               

              For instance, the API we proposed was suited to our user needs, but was too complex for jBPM, they had no need of group membership if I remember correctly. People approaching jBPM would have had a plethora of methods that was of no use for their jBPM project.

               

              Also it looks like Shane wanted to keep the Seam API, but have a simpler API in picketlink to more closely match this API, so which API would the user face ? I got confused on this aspect.

               

              I think that if we provide our own API (Seam, GateIn...) we can customize it more closely to our typical user approach. Of course a common API also has benefit since you have to learn it once for various projects but makes the first approach maybe more difficult.

               

              Now if someone comes up with a unified API that suits all our needs, that's great. It failed once, it doesn't mean it will fail twice.

              • 19. Re: Seam Security 3.0 and PicketLink
                bdaw

                Seam proposal is mostly about grouping and duplicating existing methods as most of methods in discussed "IdentityManager" are available in other places of API - exact or in a bit more complex form. While I perfectly understand your needs to provide users with a simple interface with minimal set of methods I fear that in the long run such approach can make the entire API a bit bloated. I don't point at interface proposed by Shane here - like I wrote before I have a mixed feelings and maybe it is a good idea to have a "simplified" part of API in such shape. However like Thomas pointed it is not really possible to have a perfectly common API that will be enough for every project. Some other projects may prefer to have few additional methods in "SimpleIdentityManager" while others would like few less. This will likely lead to API extensions anyway. From what Shane told me you plan to expose PLIDM API so in the end you would have additional extension interface that in fact doesn't add anything new but rather a subset of what PLIDM provides.

                1 2 Previous Next