Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Darran Lofthouse
Darran Lofthouse [https://community.jboss.org/people/dlofthouse] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11955
--------------------------------------------------
Another option could be.
Split the JAAS configuration portion of the security subsystem into it's own schema. Reference it from both the as config schema and the security subsystem schema and modify the portion of the security subsystem that operates on this to be able to parse these elements when defined in the security subsystem AND within a security realm. That way instead of referencing the domain we could just define the login module stack directly in the realm.
Using JAAS in the host controller has been problematic as well so would solve that problem for some users.
--------------------------------------------------
9 years, 9 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Darran Lofthouse
Darran Lofthouse [https://community.jboss.org/people/dlofthouse] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11954
--------------------------------------------------
"Ideally it should be the location of all security configuration. I do encourage moving the configuration to the security subsystem."
The security subsystem is not available within the host controller process - this is the reason we can not use the security subsystem for domain management. Having some form of subsystem support in the host controller is part of the much longer term plan - at that point yes re-using the subsystem will be desirable to ensure a unified security configuration across the whole AS but as it stands today moving the items to it is just not practical.
Once subsystem support is available it would also be desirable to re-use the web susbystem to take advantage of any additional config there as well.
This is horrible for threaded discussions - any chance we could move this to a mail thread?
--------------------------------------------------
9 years, 9 months
[JBoss ESB Development] - Calling remote ESB client error
by Martin Myslík
Martin Myslík [https://community.jboss.org/people/m.myslik] created the discussion
"Calling remote ESB client error"
To view the discussion, visit: https://community.jboss.org/message/810225#810225
--------------------------------------------------------------
Hi, I am trying to send and esb message from remote client, but I am constantly getting this error:
org.jboss.soa.esb.listeners.message.MessageDeliverException: Invocation exception. null
at org.jboss.soa.esb.client.ServiceInvoker.loadServiceClusterInfo(ServiceInvoker.java:545)
at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:174)
at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:155)
at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:197)
at cz.certicon.esb.test.SenderESB.sendAMessage(SenderESB.java:24)
at cz.certicon.esb.test.Manager.sendESBMessage(Manager.java:94)
at cz.certicon.esb.test.MyFrame.actionPerformed(MyFrame.java:120)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source).........
I found many tutorials on setting up remote client, but none of them helped me.
I am using JBoss AS 6 with ESB 4.11 and running my application from Eclipse (with JBoss Tools). Sending JMS messages work fine, but I cant make this work.
This is my sample code for sending esb messages:
| public void sendAMessage(String message) throws Exception { | |
| System.setProperty("javax.xml.registry.ConnectionFactoryClass",| "org.apache.ws.scout.registry.ConnectionFactoryImpl"); |
| | | Message esbMessage = MessageFactory.getInstance().getMessage(); |
| | | esbMessage.getBody().add(message); |
| | | new ServiceInvoker("FirstServiceESB", "SimpleListener").deliverAsync(esbMessage); |
| | } |
1) I have JBossESB runtime and JBoss 6.0 runtime imported (including all the libraries they provide).
2) I included jbossts-common.jar
3) I have jboss-esb.xml, uddi.xml and jbossesb-properties.xml in META-INF directory (I include these files as attachment, the last two are copied from helloworld quickstart...)
I honestly dont know what else to do to make it work... any kind of help is appreciated!
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/810225#810225]
Start a new discussion in JBoss ESB Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
9 years, 9 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Heiko Braun
Heiko Braun [https://community.jboss.org/people/heiko.braun] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11953
--------------------------------------------------
> I'm not so sure that even rights to a referent are black-and-white when it comes to rights to a referrer. Just because I can read a security domain config doesn't mean I can read the config of every resource that references it. Perhaps I should be able to see all references so I know what's affected by the resource.
I can understand your point if view. IMO it depends on the question which use cases have precendence. I.e. think about a blank server configuration. Taken your example of a security domain and a remoting connector, you wold need to configure both ends. In this scenario I think we would agree that same rights on both ends (write access) are probably required.
The example that you used builds on the assumption that one end is already configured. Precendence of use cases would mean that the foremost example will used to guide the design, not the later. The question is not what are the minimum security requirements, but what are permission are required at maximum.
With regard to this I still believe, that whenever a reference is used as part of the configuration you'd require the same permissions on both ends to enable the full set of use cases that we can think of. IMO for reference this includes creation and removal of the the refernt in all cases.
Does that make sense?
--------------------------------------------------
9 years, 9 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Heiko Braun
Heiko Braun [https://community.jboss.org/people/heiko.braun] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11952
--------------------------------------------------
> consolidate all security configuration in the security "subsystem"
we just need to be clear about the distinction between application level security and domain level security. lack of separation leads to the question how the access control for different roles (i.e. operator vs admin security manager) can be realized.
an operator should be able to modify the application level security but prevented from accessing the domain level security. now if evething resides with the secuirty subsystem, we would either need very fine grained access control rules or a strict separation. My gut feeling tells the later is more comprehensible.
--------------------------------------------------
9 years, 9 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Access control notes
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"Access control notes"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48596#comment-11946
--------------------------------------------------
> Heiko Braun wrote:
>
>
>
> Reading through your examples again, I think this one shouldn't be supported:
>
>
> > do rights to the referrer grant rights to the referent
>
>
> If you don't have the same rights on both ends (which is what the sentence implies) it should be considered an illegal constraint and access to the the referent not be granted. Eventually we shoud veen take it further and consider the role as illegal (unusable) when it is associated with illegal secuty rules.
>
Let's be concrete.
If I have the right to *write* the "security-domain" attribute on a remoting subsystem connector resource, that does not require me as a user to have any rights to the security domain resource other than being able to be aware of its existence. It can be argued that I should also be required to have the ability to fully read the resource as well, although fundamentally it's the remoting subsystem code that needs that, not me as a user. In no way does it require that I be able to *write* to the security domain resource.
So, I disagree that the same rights are required on both ends.
I'm not so sure that even rights to a referent are black-and-white when it comes to rights to a referrer. Just because I can read a security domain config doesn't mean I can read the config of every resource that references it. Perhaps I should be able to see all references so I know what's affected by the resource.
I'm going to think about this in terms of something more exact. That is, what exact permissions are we talking about on each side. For example "write" permission to a referent results in modifying the effective config of a referrer, and a permission to do that is necessary, but that's a different thing from a permission to write some other attribute of the referrer.
--------------------------------------------------
9 years, 9 months