[JBoss Identity Development] - Re: AppliesTo support for STSClient (previously WSTrustClien
by sguilhen＠redhat.com
Hi Daniel,
anonymous wrote :
| I understand this as to mean that a RequestSecurityToken can be valid without a TokenType or an AppliesTo specified.
| I'm not sure how that would work and how the lookup of the service provider and token provider could be done with one or the other. Perhaps 'SHOULD' in this case is more strict then I'm interpreting it?
|
No, I think you are interpreting it correctly, otherwise they would have used the word 'MUST'. I interpret the 'SHOULD' as something highly advisable and as such I believe we can require one of the types to be specified in WS-T requests simply because we don't have any other way to find out what token provider should be used to handle the request.
We could use a default provider (specified in the WS-T configuration file) but I don't think this is a good idea because a default provider could cover a potential client-side error. In other words, the client app could be expecting an exception to be thrown if the user forgets to specify the token type or target endpoint but instead gets a 'default' token from the STS.
It is good that you've copied that section of the spec here because it reminded me that AppliesTo has precedence over TokenType and right now the STS doesn't follow this rule. I'll open a Jira and fix this.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257511#4257511
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257511
14 years, 7 months
[JBoss Identity Development] - Re: AppliesTo support for STSClient (previously WSTrustClien
by beve
Hi Stefan,
anonymous wrote : IIRC, the spec doesn't say that 'ONLY ONE' of them should be specified, so I think we can safely have both the token type and AppliesTo in the request. :)
You are right. The spec says:
anonymous wrote :
| TokenType
| If this optional element is not specified in an issue request, it is RECOMMENDED that the optional element <wsp:AppliesTo> be used to indicate the target where this token will be used. That is, either the <wst:TokenType> or the <wsp:AppliesTo> element SHOULD be defined within a request. If both the <wst:TokenType> and <wsp:AppliesTo> elements are defined, the <wsp:AppliesTo> element takes precedence (for the current request only) in case the target scope requires a specific type of token.
|
I understand this as to mean that a RequestSecurityToken can be valid without a TokenType or an AppliesTo specified.
I'm not sure how that would work and how the lookup of the service provider and token provider could be done with one or the other. Perhaps 'SHOULD' in this case is more strict then I'm interpreting it?
anonymous wrote : Regarding adding a new method, I don't have anything against it. As a matter of fact, this can be a good thing. Although the very same check is performed in the STS, a client-side validation can prevent us from spending time to create, marshall, and dispatch a request that will fail anyway.
I agree. I'll add this.
Thanks,
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257460#4257460
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257460
14 years, 7 months
[Embedded JBoss Development] - Re: ShrinkWrap - Descriptors
by epbernard
OK cool, sorry I did not know. So ContainerBase is really a facility class and youa re already doping what I was describing.
BTW I dont' think specializes(Class<T extends Archive> clazz, Path basePath) should be here, what does it do to a real user, what's the use case?
WarArchive war = ear.specializes(WebArchive.class, "my.war");
should raise an exception IMO as we do not specialize, we actually add a new archive inside an archive. An EAR contains a WAR, it is not a WAR.
So if I sumamrize, a descriptor is a super interface of archive that describes a given configuration file like web.xml. Why separate it from the WebArchive interface exactly?
Also remember that some configuration files can be at disfferent places and be multiple. For example in JPA, orm.xmls can be named as it pleases you and you can add many of them.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257444#4257444
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257444
14 years, 7 months
[JBoss ESB Development] - EBWS Security Support
by beve
I'm working on "Web service publishing support for ESB services ignores WS-Security. " https://jira.jboss.org/jira/browse/JBESB-2552.
This task has to concerns:
1. Add support for container security
2. Add support for ESB Service security
1. Add suppport for container security
Every EBWS in the same jboss-esb.xml will share the same war. Also, any http providers will also share this same war. This brings up the question about how do we configure container security for EBWS since a war can only have a single security domain?
My question is how do we want to configure the container security for EBWS in this shared war model?
Should there be a separate global configuration in jboss-esb.xml that defines the security domain that will set the security domain for the war.
2. Add support for ESB Service security
Should EBWS be a special case where the normal ESB security is ignored and and we let the container handle security for us. This will make the service unsecured to a stand-alone client using the ServiceInvoker to directly call the service by-passing the gateway (EBWS in this case). But this might be OK?
What are your thought on this?
Regards,
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257415#4257415
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257415
14 years, 7 months
[Embedded JBoss Development] - Re: ShrinkWrap - Descriptors
by aslak
"epbernard" wrote :
| "aslak" wrote :
| | They all 'share' the same base Archive impl as a backing, so there is no problem having code like this:
| |
| |
| | | WebArchive war = new WebArchiveImpl(new MemoryMapArchiveImpl());
| | | EnterpriseArchive ear = new EnterpriseArchiveImpl(war.getInternalArchive());
| | |
| |
|
| well this code is fugly, that's a huge problem :)
|
Hehe, yes, that is fugly, but it was just to illustrate that the WebArchives backing can easily be moved to run as the EnterpriseArchives backing.
"epbernard" wrote :
| "aslak" wrote :
| |
| | | EnterpriseArchive ear = new EnterpriseArchiveImpl(new MemoryMapArchiveImpl());
| | | WebArchive war = ear.getWebModule("my.war");
| | |
| |
| That's a different scenario here, you are creating a new archive so a dedicated method makes sense.
|
True, but the getWebModule() impl would use the specializer api internally was the point.
"epbernard" wrote :
| Still it seems to me that delegation is less heavy on the specializer implementation and subclassing the core archive impl does not give you much.
|
I'm not sure I understand. The way it is today is as following:
interface WebArchive extends ResourceContainer, ClassContainer....
WebArchiveImpl extends ContainerBase implements WebArchive -> has a Archive
WebArchiveImpl is a pure delegator to the Archive, but with some fixed prefix Paths etc to follow the War spec, ie ClassContainer mappes to /WEB-INF/classes/.
There is no subclassing of the backing Archive(MemoryMapArchiveImpl) in WebArchiveImpl.
The different archive extensions(WarArchive, EnterpriseArchive etc) extend a common ContainerBase class, but that is only as a convenient way of implementing the diff containers.
I see no problem with adding a spercializes method to the Archive interface and having a common impl in the ContainerBase(or even ArchiveBase) to load the spercialized impl. Something like.
| public class ContainerBase {
| ...
| T specializes(Class<T extends Archive<T>> clazz) {
| return specializes(clazz, new BasicPath("/"))
| }
|
| T specializes(Class<T extends Archive<T>> clazz, Path basePath) {
| pesudo:
| lookup delegation implementation of clazz, ie WebArchiveImpl
| return new WebArchiveImpl(basePath, this.backingArchive);
| }
| ...
| }
|
This will open up for:
| EnterpriseArchive ear = ...
| WarArchive war = ear.specializes(WebArchive.class, "my.war");
|
| war = ear.getWebModule("my.war") {
| return this.specializes(WebArchive.class, "my.war");
| };
|
| JavaArchive jar = ...
| WebArchive war = jar.specializes(WebArchive.class);
|
|
The 'Descriptor' part is a bit different since it operates on the content of a Asset, but if we turn them around to be pretty much the same as the archive extensions ie:
WebArchiveDescriptor has a Archive.
and WebArchive no long impls WebArchiveDescriptor
we could do
| WebArchive war =
| WebArchiveDescriptor desc = war.specializes(WebArchiveDescriptor.class);
| desc.addServlet()...
|
Which is what you're referring to I guess..
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257398#4257398
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257398
14 years, 7 months
[Embedded JBoss Development] - Re: ShrinkWrap - Descriptors
by epbernard
"aslak" wrote :
| They all 'share' the same base Archive impl as a backing, so there is no problem having code like this:
|
|
| | WebArchive war = new WebArchiveImpl(new MemoryMapArchiveImpl());
| | EnterpriseArchive ear = new EnterpriseArchiveImpl(war.getInternalArchive());
| |
|
well this code is fugly, that's a huge problem :)
anonymous wrote :
|
| | EnterpriseArchive ear = new EnterpriseArchiveImpl(new MemoryMapArchiveImpl());
| | WebArchive war = ear.getWebModule("my.war");
| |
|
That's a different scenario here, you are creating a new archive so a dedicated method makes sense.
anonymous wrote :
| This should of course be hidden away in some 'specializes' like api, but the point is the same.
|
Still it seems to me that delegation is less heavy on the specializer implementation and subclassing the core archive impl does not give you much.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257372#4257372
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257372
14 years, 7 months