1 2 Previous Next 24 Replies Latest reply on Dec 5, 2008 2:37 PM by anil.saldhana

    SAML Assertions  (JBossESB)

    jkurtz.wa

      Starting this to get some feedback on how SAML Assertions can be used with JBoss, especially JBossESB/Web Service Messaging. There are a number of applications for Web Based Identity Management, but there is nothing specific for an ESB.

      The SAML Assertion itself should not change, and it appears like the Protocols (authentication flow) could all be used. There are SOAP bindings that could be adapted, but more research needs to be done just to understand how. Possibly, the message header could be treated like a SOAP header, but there is more work to be done.

      A good place to get some background on SAML

      http://en.wikipedia.org/wiki/SAML_2.0#SAMLBind

      From a high-level view, it looks like the components needed are:
      1. Means to create/manage/validate the SAML Assertions
      2. Which Protocols make the most sense and how to implement the best ones within JBoss ESB
      3. Looking at the Bindings and determining how the SOAP ones fit into JBoss.


      Any questions, feedback or comments are appreciated.

        • 1. Re: SAML Assertions
          anil.saldhana

          We are going to be providing a SAML2 stack for both the server bindings (web profiles) as well as an infrastructure to create/transport assertions, as part of the JBossIdentity project. There will be both a web container support as well as non-web-container support. I have the code on my laptop. I need to pull it together this month.

          I am not sure why your design post talks about a general saml framework for JBoss. Can you please align your discussions for JBossESB?

          • 2. Re: SAML Assertions
            anil.saldhana

            John, what would be the various integration points in ESB? From my recollection, the ESB message can contain security context. So an action can be an integration point.

            Then there are the business containers. There, we probably utilize Application Server security. For JMS, I guess we can utilize standard security.

            I would like to see where are the integration points in the ESB machinery, where security can be applied, that is not provided by any containers such as WS, EJBs, JMS etc.

            • 3. Re: SAML Assertions
              anil.saldhana

              For WS, you can take a look at ws-security tokens (username, x509) and then utilize saml assertions.

              • 4. Re: SAML Assertions  (JBossESB)
                jkurtz.wa

                Anil

                The Integration point for a JBoss ESB Service could be an action class or Spring Listener class. This class could be the Policy Enforcement Point (PEP) for either authentication or authorization. The PEP would then call out to some mechanism, pluggable of course, to perform the analysis.

                >>For authentication the PEP would need the SAML Assertion or some other identity token

                >>For authorization using XACML the PEP needs the Subject (role), Resource and Action (optional Environment)

                The SAML Assertion (or other identification token) can be placed in the message header for both the ESB and web Service. Meta-data for authorization could be placed there too.

                I am looking into some open source identity managers and service providers.

                • 5. Re: SAML Assertions  (JBossESB)
                  anil.saldhana

                   

                  "jkurtz.wa@gmail.com" wrote:

                  I am looking into some open source identity managers and service providers.


                  This is what needs to be built using JBoss Identity (of course in a few days).

                  • 6. Re: SAML Assertions  (JBossESB)
                    jkurtz.wa

                    anil

                    Have you thought about using smooks to do the conversion of the SAML Assertion into Java and back to XML? If you want, I can create the component, just point me to some SAML assertions and I will make the software and test cases.

                    I have the SAML Assertion schema and can generate the test cases for this component if you want. I would follow the way that XACML does its conformance testing. This might find its way into the SAML Spec, at least the tests.

                    John

                    • 7. Re: SAML Assertions  (JBossESB)
                      marklittle

                       

                      "jkurtz.wa@gmail.com" wrote:

                      The Integration point for a JBoss ESB Service could be an action class or Spring Listener class. This class could be the Policy Enforcement Point (PEP) for either authentication or authorization. The PEP would then call out to some mechanism, pluggable of course, to perform the analysis.


                      I'm not so sure about that. Certainly in Overlord where we have been looking at PEPs from a governance perspective, filters/interceptors seem more appropriate since they can be imposed by the infrastructure.

                      • 8. Re: SAML Assertions
                        marklittle

                         

                        "anil.saldhana@jboss.com" wrote:
                        John, what would be the various integration points in ESB? From my recollection, the ESB message can contain security context. So an action can be an integration point.


                        It could be enforced within an action, or within filters. Since filters are imposed by the infrastructure and do not rely on the application or service configuration being right (or deliberately spoofed) they would seem to be more appropriate.

                        • 9. Re: SAML Assertions  (JBossESB)
                          marklittle

                          BTW, for the purposes of this discussion I'm assuming that we just need to agree that there is such a thing as a PEP or equivalent in the components that require hooks for identity/authentication. It obviously shouldn't be mandated by this framework how they are implemented by those components/projects only what they need to do in order to conform.

                          • 10. Re: SAML Assertions  (JBossESB)
                            anil.saldhana

                            PEPs (as Mark pointed out) are basically intercepting entities. So actions, filters, interceptors etc... fit the bill.

                            • 11. Re: SAML Assertions  (JBossESB)
                              jkurtz.wa

                              For Authorization, the PEP could accept a Subject, Resource and Action. The Subject could be an authenticated user or role, the Resource would be the entity being protected and action what the user wants to do.

                              For example, for someone wanting to read data from a personnel database, the subject could be a user role, resource would be the database and action would be a read.

                              This fits right into the XACML spec and could be adjusted to fit most policy-based authorization needs.

                              Would the authentication PEP follow the SAML spec? They have some good features within an Assertion. I have a Class Diagram of an Assertion and am using it with smooks to read and write data to the SAML Assertion. I will post the UML diagram and some SAML assertions to see if it captures it. I will also generate some SAML test cases similar to the compliance tests for XACML.

                              • 12. Re: SAML Assertions
                                jkurtz.wa

                                 

                                "mark.little@jboss.com" wrote:
                                "anil.saldhana@jboss.com" wrote:
                                John, what would be the various integration points in ESB? From my recollection, the ESB message can contain security context. So an action can be an integration point.


                                It could be enforced within an action, or within filters. Since filters are imposed by the infrastructure and do not rely on the application or service configuration being right (or deliberately spoofed) they would seem to be more appropriate.


                                Mark, could you elaborate on this? This is really an important point. I am going to look for some examples of filters and will work through the examples to understand further.

                                • 13. Re: SAML Assertions  (JBossESB)
                                  marklittle

                                  Sure. The problem with Actions is that they require the deployer to add them in, whereas filters can be imposed by the infrastructure. Furthermore, the filters can be applied across all services, i.e., they are global.

                                  • 14. Re: SAML Assertions
                                    jeff.yuchang

                                     

                                    "jkurtz.wa@gmail.com" wrote:
                                    "mark.little@jboss.com" wrote:
                                    "anil.saldhana@jboss.com" wrote:
                                    John, what would be the various integration points in ESB? From my recollection, the ESB message can contain security context. So an action can be an integration point.


                                    It could be enforced within an action, or within filters. Since filters are imposed by the infrastructure and do not rely on the application or service configuration being right (or deliberately spoofed) they would seem to be more appropriate.


                                    Mark, could you elaborate on this? This is really an important point. I am going to look for some examples of filters and will work through the examples to understand further.


                                    Hi John,

                                    As Mark mentioned the filter, it reminds me of this great feature. So today, I've looked into the filter feature again. Have some thoughts on adding security feature by using filter.

                                    Right now, we extract the security information in the Gateway, and then do the authentication in the service actionProcessingPipeline.

                                    With introducing a securityFilter, we will do the extraction work on the onOutput(...), which before leaving Gateway. onInput(...) will do the seucirty enforcement. And then we just need to configure the $jbossesb/server/default/jbossesb.sar/jbossesb-properties.xml by adding the securityFilter.

                                    In this way, the security feature becomes very pluggable.

                                    If I understands codes correctly. The process will be like:

                                    Message -> Gateway -> Filter.doOuput -> Transport -> Filter.onInput -> Service1 -> Filter.onOutput -> Transport ->....
                                    

                                    So the Gateway will only has the Filter.onOutput, no onInput though. But for service level, it has both onInput and onOutput.

                                    Hope this Helps.

                                    Jeff

                                    1 2 Previous Next