6 Replies Latest reply on Nov 8, 2010 6:58 AM by Boleslaw Dawidowicz

    Custom IdentityStore for GateIn

    James Bragg Newbie

      Not sure if I should post this here or in the PicketLink Community


      I am in the process of implementing a custom IdentityStore for our portal (JEPP 5) because of our exist User Authorization and Authentication legacy system.  We have also decided to implement the SPI interface so that we have more flexiblity later on; however, one of the challenges that I am having is understanding exactly how much of the SPI needs to be implemented.



      I have implemented:

      - PortalIdentityStore

      Also the IdentityObjects with their necessary business delegates:

      - PortalUser

      - PortalGroup

      - PortalGroupType (enum of the different groups to be supported)

      - PortalRelationship

      - PortalRelationshipType (enum {member,role})

      - PortalRelationshipName (the various roles to be supported)


      Questionable classes:

      - PortalCredential  (can I just reuse an existing class, do I really need my own)

      - PortalIdentityStoreSession (transactions will not be supported)

      - PortalIdentityStoreConfigurationContext (is it really necessary/reuse existing?)

      - PortalIdentityObjectSearchCriteria (reuse existing?)

      - PortalFeaturesMetaData (reuse existing?)

      - what else??


      And what about implementing PortalOrganizationService (In my opinion, this is the most critical class as gatein uses it the most)


      I guess another item that I need to understand is:  How should I look and implementing this?


      - Does GateIn OrganizationService implementation uses the PicketLink IDM?


      - Does GateIn's PicketLink IDM implementation use their OrganizationService implementation?


      I have gone through GateIn's and PickletLink's documentation several time but is still having trouble making since of what specific implementations that I need to implement. I believe its that whole 'Too much abstraction' thats getting to me even using the SPI.


      Any help would be greatly appreciated!!





        • 1. Re: Custom IdentityStore for GateIn
          James Bragg Newbie

          I'm just curious if anyone reads these post.... Seems that at least mine are mostly ignored....


          Its hard to believe that I've been working on trying to implementation my custom web service Identity Store is know luck and no help from the group....    With our deadline next week, I'm afraid we will have to cancel this project and move to .NET   I'm starting to see why management wants to move away from open source...



          • 2. Re: Custom IdentityStore for GateIn
            Rich Raposa Novice



            Sorry no one replied to your initial post. You asked a lot of questions about a topic that many of us don't have experience doing (myself included!). Have you read the following post? It has some good tips:




            Have you looked at the source code to see how the built-in implementations were written? You might be able to customize one of those to fill in the missing pieces of your implementation.




            • 3. Re: Custom IdentityStore for GateIn
              Boleslaw Dawidowicz Master

              Hi, to be honest I simply missed you post. Maybe something with notification emails...


              OrganizationService implementation is the wrapper around PicketLink IDM that performs some translations between object models. In your case implementing OrganizationService could be the simplest approach but the risk is that in future versions of GateIn this API can become deprecated and legacy. Nothing is decided atm but PicketLink IDM SPI is more likely to remain.


              For PicketLink the best would be to look at the codebase. This is not really documented at the moment (hope to change it soon) but as you see LDAP and Hibernate implementations are in separate maven artifacts. Hibernate implementation is the default and support all of SPI futures while LDAP only part of them (without roles). For example with LDAP integration Hibernate store is still in use and any operation or relationship not supported by LDAP store fallbacks to Hibernate and DB.


              For the SPI interfaces you will find simple implementation of most of them in picketlink-idm-core artifact so you don't need to implement things like IdentityObjectCredential, IdentityObjectAttribute or IdentityObjectType and etc. Probably implementing IdentityStore and IdentityObject would be enough. Like I said source code is probably the best guide at the moment.

              • 4. Re: Custom IdentityStore for GateIn
                Thomas Heute Master

                James, you should inform your management about what we call professional Open Source, with the enterprise Portal Platform, you get to have people dedicated to answer issues faced by customers and you also have a guaranteed SLA.

                • 5. Re: Custom IdentityStore for GateIn
                  James Bragg Newbie

                  Thomas/Boleslaw, thanks for replying, I do appreciate it..


                  Sorry, if I was too harsh, in my previous response, way too may long hours and no real progress on this.  I am sure that I am making this much hard than it needs to be (over analyzing).


                  To be honest, we actually do have a service contract for JEPP 5.0, we were included has one of the earlier adopters back in April.  The original consultants that we had from one of JBoss's consulting companies where the ones that recommended that we implement our integration by implementing the SPI.  But to be honest, even their knowledge and understanding of Gatein was limited.  Additionally, I was hoping the user forum would be able to "educate" me instead of just giving me a solution.. Furthermore, in past experiences some responses that we have gotten from JBoss is: If we are using a framework that is not supported my JBoss then they would not help (using Spring instead of Seam.....) Now I do know over the past couple of month, JBoss has been attempting great stride to improve their support in this area.


                  As it stands now, I believe we will have to by-pass the complete integration with IDM since we have missed our initial deadline, by a month and and are now about to miss our second deadline (this coming Monday morning).  So I believe that my only solution, that will make our deadline will be to configure an Identity store to connect to our AD LDAP server to authenticate and pull users, and extend the DefaultRolesExtractorImpl and call our web service to pull in the users roles.


                  Because we have to extended the UserACL so that we can implement our own ContextBased ACL, there should be a limit impact of by-passing the included IDM.  In my opinion, the following are objects that I believe we had on implementing our SSO and Identity Management solution with Gatein, in order of preference:


                  1. Implement IdentityStore (SPI)
                  2. Implement IdentityStore (API)
                  3. Implement Custom OrganizationService
                  4. Configure PicketLink to LDAP and extend DefaultRolesExtractor and by pass Out of the Box UserAdministration portlets.


                  Again, I believe that I have made this much more difficult than it needs to been, it just comes down to truely understanding no only the IdentityStore but what all the other object it uses.  And if they are "required" by some other piece of the Portal.


                  Once we get our initial release and if management approves I will see if I an go back and implement the Identity Store using the API. I believe that this may have been an easier solution over the SPI implementation.


                  And again thanks for responding...  I you would like more specific information on what we were attempting to implement please let me know.  Once everything is done and I can breathe again I will be opening some JIRAs for items that I have found throughout our development.



                  • 6. Re: Custom IdentityStore for GateIn
                    Boleslaw Dawidowicz Master



                    Like I wrote previously I hope to make implementing PicketLink IDM SPI easier in the future but at the moment you need to dive in into the codebase.

                    Any call to PicketLink IDM APIs goes via OrganizationService interface (UserHandler, GroupHandler and etc) so for the fastest way to plug different kind of storage is to simply implement those interfaces and cut off picketlink idm completely. But like I wrote this may lead to additional work in future versions if those API changes or become deprecated.