[JBoss ESB Development] - Re: SAML Token Support
by beve
anonymous wrote : Can someone please explain why it was decided to write an action to do this rather than use the LoginContext/LoginModule approach? Is there any technical reason why that would not work with SAML?
I can't really say that this was a technical reason for this. It just seemed appropriate that the LoginModule should only do one thing and that was to validate an existing token from a calling client.
The client would have somehow called an STS to have a security token issued for the target service. And if the client was the ESB itself it could use the action to have a security token issued for an endpoint that it is going to call.
anonymous wrote : From what I understand, the SAML token is just another credential and it seems to make more sense for this to be handled indirectly, through javax.security, rather than through direct integration.
Sorry, I'm not following your suggested solution here. Could you expand on what you mean for this to be handled indirectly with javax.security.
Thanks,
/Dan
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261257#4261257
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261257
16 years, 5 months
[Embedded JBoss Development] - Re: embedded and bootsrap dependencies
by emuckenhuber
"ALRubinger" wrote : "emuckenhuber" wrote : Yes, i think it's better under it's own umbrella :)
|
| OK. I'm still not seeing the advantage. Will find you on #jboss-dev tomorrow so we can discuss some more.
|
Sure, we can talk there as well. Let's put it the other way around - i'm actually wondering why it's part of bootstrap.
Maybe i have just a different view of what the bootstrap project is about, as for me it's a contract for starting/stopping a server - therefore i think a deployment-api is misplaced there. Technically you can most probably achieve the same no matter where you put it - i was just confused seeing that in bootstrap. Maybe it's the most natural thing for other users, don't know :)
"ALRubinger" wrote :
| "emuckenhuber" wrote : Hmm, we could briefly talk about the deployable as well - as i can tell for sure that ProfileService won't expose a VDF deployment.
| | Maybe we want to just rename the VfsVdfDeployableFactory to a DeployableFactory? In the end it should not really matter what deployable is created and i don't think there should be 2 different types - like VdfDeployable and PSDeployable - at the same time.
|
| More to discuss. Keep in mind the idea behind Container/Deployable is to be as generic as possible, as the TCK299 test utils will be leveraging the same contract.
|
Yes, i agree that it should be a generic contract. That's why i was suggesting having something like:
| DeployableFactory
| {
| Deployable create(String name, InputStream archive);
| Deployable create(File archive);
| Deployable create(URL archive);
| }
|
Maybe as well one for creating a Deployable based on a shrinkwrap archive. All the code is already there. I'm just suggesting not using the name VfsVdfDeployableFactory - as the name somehow implies a VFS and VDF based deployable.
In the end which deployable is created should not matter for the user and is more related to what embedded can deploy.
"ALRubinger" wrote :
| "emuckenhuber" wrote : [OT] out of curiosity - it seems that when creating a deployable you are creating a zip out of the shrinkwrap in-memory archive.
| | When i first looked at the archive stuff - i thought you are directly deploying this in-memory VirtualFile. Is there a specific reason why you don't do that?
| | Well, as it gets zipped it could be interesting to use that also in standalone testing.
|
| Yeah. VFS is a filesystem abstraction, but MemoryFile does not support the full range of VFSFile operations in the same fashion as from a traditional flat file root. So we use ShrinkWrap to represent the mutable object view of an archive and ultimately flush that to a temp file which becomes the deployable. At that point, Embedded/AS doesn't know/care the difference from where the archive originally came from,and the Embedded suite passed without further issues. For instance, JBossWeb and Hibernate both have filesystem dependent code and may fail when using MemoryFile.
I see, well i thought the VFS temp thingy would take care of creating (real) temp files usable by jboss.web - but i know that you had other issues as well. So i was just curios about if it would have worked without zipping it. As said it makes it also usable for remote deployments, so it actually seems to be a good thing.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261253#4261253
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261253
16 years, 5 months
[JBoss ESB Development] - Re: SAML Token Support
by Kevin.Conner＠jboss.com
I am just coming to this late and for that I apologise.
"beve" wrote : The issuing of a SAML Assertion will be performed by an action in the ESB called JBossSTSAction.
Can someone please explain why it was decided to write an action to do this rather than use the LoginContext/LoginModule approach? Is there any technical reason why that would not work with SAML?
>From what I understand, the SAML token is just another credential and it seems to make more sense for this to be handled indirectly, through javax.security, rather than through direct integration. This would also make it easier when we come to enforce the java security manager integration as we are likely to prevent all actions from modifying this context.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261239#4261239
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261239
16 years, 5 months