-
1. Re: SAML Assertions
anil.saldhana Nov 3, 2008 8:43 PM (in response to jkurtz.wa)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 Nov 3, 2008 8:58 PM (in response to jkurtz.wa)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 Nov 3, 2008 9:02 PM (in response to jkurtz.wa)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 Nov 5, 2008 6:36 PM (in response to 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 Nov 5, 2008 6:48 PM (in response to jkurtz.wa)"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 Nov 6, 2008 6:15 PM (in response to 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 Nov 7, 2008 11:07 AM (in response to jkurtz.wa)"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 Nov 7, 2008 11:08 AM (in response to jkurtz.wa)"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 Nov 7, 2008 11:12 AM (in response to jkurtz.wa)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 Nov 7, 2008 11:58 AM (in response to jkurtz.wa)PEPs (as Mark pointed out) are basically intercepting entities. So actions, filters, interceptors etc... fit the bill.
-
11. Re: SAML Assertions (JBossESB)
jkurtz.wa Nov 8, 2008 5:42 PM (in response to 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 Nov 8, 2008 5:47 PM (in response to 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 Nov 9, 2008 9:21 AM (in response to jkurtz.wa)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 Nov 10, 2008 5:46 AM (in response to jkurtz.wa)"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