[JBoss AS7 Development] - Management API Security Authorization Responsibility
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Management API Security Authorization Responsibility"
To view the document, visit: http://community.jboss.org/docs/DOC-16583
--------------------------------------------------------------
h1. Authorization Responsibility
An ACL scheme for the authorization checks is still to be defined as it is not a priority at this stage, this document however is to capture the optimum locations that the authorization checks will occur.
When a request is recieved by from a client for a management operation this request can affect anything from the whole domain to individual nodes in the domain, it is quite possible that an administrator could send a request for which they have the permission to perform the majority of the requested operations but some aspects may be prohibited - this is not nescesarily due to the administrator deliberately attempting to perform prohibited actions but could be caused by the use of wildcards within addresses.
When performing the authorization check it is desirable that if the request is going to fail due to an authorization check that this failure is detected early so we do not need to rely on compendating operations to reverse a partially applied request.
h2. General Approach
The general approach for authorization is that after a request is recieved that may involve a compound operation or my involve wildcard addresses this operation should be 'resolved' to identify the real operation calls that this will result in - this list can then be checked before it is executed to verify that the calling user is authorized to perform all operations.
This is assuming a centralised ACL scheme covering a whole domain rather than ACL definitions defined independently on each host.
h2. Call Routing
The flexible nature of the domain architecutre means that there are multiple ways operations can be requested and transferred to the hosts that will end up acting on them,
h3. Internal / Start-Up
The bootstrap process for the JBoss AS domain configuration involves the parsing of the configuration and the calling of numerous operations to start and configure the actual servers and the required services.
There may also be a need for further operation requests to be executed after being requested internally.
All requests originating in this way should be automatically authorized.
h3. Client -> Standalone
This is the simplest scenario where a client is calling the management APIs exposed by the running standalone instance.
Authorization will follow the basic steps highlighted at the start of this article and the operations will be resolved and and authorization check performed.
As this is standalone there is no requirement to consider remote nodes.
h3. Client -> Domain Controller -> Domain Slave
I would expect this to be the dominant use case for administration when working with domain deployments, the administrator will connect to the management API of the domain controller and the requests will be passed to the slave domain controllers to be passed to the servers running on that host.
On start up the domain slave will have established a connection to the domain controller, the trust mechanisms are being covered in a different article but for the point of considering the authorization checks this connection can be considered a trusted connection.
For authorization the domain controller will have performed the resolve step to break down the request into the discrete steps, and authorization check will then be performed on the steps before passing the request to the relevent slave domain controllers.
The slave domain controllers can assume all requests coming over this connection are authorized and no further checks will be performed, this will also mean the slave domain controller works the same regardless of if this is bootstrap type start up requests or live requests from an administrator.
h3. Client -> Domain Slave
In this scenario the client has established a direct connection to the slave domain controller of a host, this scenario is most likely if the administrator is specifically interest in the running state of a specific host or are making changes for the host.xml of that host.
The slave domain controller will be required to have access to the same ACL scheme as defined on the domain controller
This is very similar to the standalone scenario (in terms of the authorization requirements at least) - the request will be 'resolved' to identify the resulting steps and these will be verified for authorization before the request is executed.
h3. Client -> Domain Slave -> Domain Controller -> Domain Slave (Optional)
+(*Note:* we have decided not to support this call pattern any time in the forseeable future. So the following discussion is for reference only.)+
This final scenario adds some additional complexity, if a slave domain controller receives a request from a client that needs to be handled by the master domain controller this request will be passed to the domain controller to execute.
This needs further consideration as the authentication / authorization is not as clean.
One option is that the domain controller that recieves the request performs the full authentication / authorization before passing to the master so the master will trust this request is authorizaed - however I don't believe the slave will have all the information available if this is a cross domain request, there is also a question as to if you should place that much trust in the slave domain controller.
A variation of the first option is that when the request is passed to the domain controller the principal of the caller is also passed along with their roles - the master domain controller can then use this for the authorization check. This solves one problem from the first option but still leaves the question regarding how much do you trust the slave.
A third option is that the credentials used to authenticate the client are passed to the domain controller so a full authentication / authorization check can be performed there. This does then help remove trusting a slave domain controller but now credentials that need to be protected are being passed from node to node.
A final option is to prohibit this scenrio and instead if a slave domain controller recieves a request it can handled a redirect should be returned so the client can connect to the master domain controller.
(If we were to use a signed security token then for this final scenrio is would be easier to support this scenario by allowing the token to be passed to the master domain controller it would then be able to verify the token as if it had been recieved directly whilst avoiding a scenario of passing credentials from node to node)
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16583]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 5 months
[JBoss AS7 Development] - Management API Security Key Decisions
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/brian.stansberry] modified the document:
"Management API Security Key Decisions"
To view the document, visit: http://community.jboss.org/docs/DOC-16586
--------------------------------------------------------------
h1. Key Decisions
This article tracks the key decisions to be made regarding the security of the management APIs.
h2. Traditional Authentication or Security Tokens
This problem was introduced closely related to authentication caches - without the overhead invovled during authentication this would purely be about personal preferences.
http://community.jboss.org/docs/DOC-16452 Design Consideration - Management API Authentication Caching
The following article highlights some of the advantages and disadvantages of each approach.
http://community.jboss.org/docs/DOC-16584 Management API Security Token vs Per Node Authentication
h3. Decision
|| *Option* || *Comments
* ||
| Traditional Only |
|
| Security Token Only | Not an option; we need both the Remoting SASL integration and also HTTP standard based integration |
| Traditional Only then add Secutiry Token Support | This is our choice, but the security token is not a high priority. Will not be in 7.1 |
h2. Authentication Mechanisms (Server Side)
Regardless of if we stick with traditional authentication or use a security token some form of authentication will still be required first to provide the security token.
The following article discusses these options.
http://community.jboss.org/docs/DOC-16574 Management API Security Authentication Mechanisms
h3. Decision
|| *Option* || *Comment* ||
| Support a simple property file based authentication? | Yes |
| Support LDAP based authentication? | Yes |
| Support Database based authentication? | Eventually; lower priority. May not be in 7.1 |
| Support delegate to domain controller type authentication? | Lowest priority. |
h2. Authentication Mechanism (Transport)
The following article explores how exposing our own APIs now gives us some flexibiliy regarding how to handle different authentication mechanisms for the transport.
http://community.jboss.org/docs/DOC-16587 Management API Security Transport Authentication
Essentially we can now dynamically identify one of a number of potential mechanisms from a single request instead of the previous servlet container based approach where you would need to forward to different deployments to use different mechanisms.
h2. Host to Domain Controller Authentication
The following article explores the authentication and establishment of trust between the remote host and the domain controller.
http://community.jboss.org/docs/DOC-16579 Management API Security Host to Domain Controller Security
Essentially the host is just a special type of user, initially no different to any other administrator but at some point when ACLs are defined we can review adding an ACL for 'register host' or something similar.
No decisions here unless there are additional comments?
This does imply that an exposed management API may need to support multiple authentication mechanisms at the protocol level as support certificates for the host to domain controller connection does not nescesarily mean a desire for administrators to also use certificates when they connect.
h2. Configuration Options
The security is going to require additional configuration for the definition, as the only configuration made available so far is which APIs to expose there are no pre-existing placeholders to insert the security configuration.
The following article shows the current configuration.
http://community.jboss.org/docs/DOC-16494 Management API Security Configuration
The following article starts to explore in terms of traditional authentication how this could be defined.
http://community.jboss.org/docs/DOC-16576 Management API Security Possible Configuration Samples
h3. Decision
|| *Option* || *Comment* ||
| Prefer configuration focussed in domain.xml? |
|
| Prefer configuration focussed in host.xml? |
|
h2. Database Connection Pool
We are required to integrate with existing security infrastructure, this means we will need to support a Database login module so we will require connections to the database.
h3. Decision
Who will previde the connection pool?
|| *Option* || *Comment* ||
| Provided by the management security implementation. |
|
| Will be provided as part of another task. |
|
h2. Authorization Checks
At this stage out only requirement is to verify that the user is authenticated, the following raises points to consider regarding how authorization checks will be performed depending on how a request reaches the management API on any host.
http://community.jboss.org/docs/DOC-16583 Management API Security Authorization Responsibility
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16586]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
12 years, 5 months
[JBoss ESB Development] - Exception while accessing admin-console
by Shafiulla Syed
Shafiulla Syed [http://community.jboss.org/people/ssyed] created the discussion
"Exception while accessing admin-console"
To view the discussion, visit: http://community.jboss.org/message/630169#630169
--------------------------------------------------------------
Hi,
I have installed 'jbossesb-4.10' on 'jboss-5.1.0.GA'. I am able to deploy and run the examples.
But when I try to see 'admin-console', I get the following exception.
Please suggest me how can I solve this issue.
java.lang.NoClassDefFoundError: org/rhq/plugins/jmx/MBeanResourceDiscoveryComponent
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.rhq.core.pc.plugin.PluginComponentFactory.instantiateClass(PluginComponent
at org.rhq.core.pc.plugin.PluginComponentFactory.getDiscoveryComponent(PluginComp
at org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor.discoverForResource(Runtime
at org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor.runtimeDiscover(RuntimeDisc
at org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor.call(RuntimeDiscoveryExecut
at org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor.call(RuntimeDiscoveryExecut
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$30
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sched
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException: org.rhq.plugins.jmx.MBeanResourceDiscoveryCo
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
Thanks & Regards,
Syed
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/630169#630169]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[Clustering Development] - JBOSS CLUSTER WITH SPRINGSECURITY
by Acácio Macedo Cintra
Acácio Macedo Cintra [http://community.jboss.org/people/acacio.cintra] created the discussion
"JBOSS CLUSTER WITH SPRINGSECURITY"
To view the discussion, visit: http://community.jboss.org/message/630143#630143
--------------------------------------------------------------
I'm having problems created during replication between the servers that are clustered. The error presented is the following:
++
+09/30/2011 18:16:50,142 ERROR [org.jboss.cache.marshall.CacheMarshaller300] (ajp-172.29.1.6-8809-4:) Error while marshalling object: dataVersion = null, data = 28 = {0, 1 = 1317417410088, org.ajax4jsf.application.AjaxStateHolder = @ org.ajax4jsf.application.AjaxStateHolder de51e30, usuarioSessao = @ br.gov.saude.plataformabrasil.visao.UsuarioSessaoVisao 60d2cd99, SPRING_SECURITY_CONTEXT org.springframework.security.core.context.SecurityContextImpl = @ e8652658: Authentication: org.springframework.security.authentication.UsernamePasswordAuthenticationToken @ e8652658: Home: @ br.gov.saude.plataformabrasil.model.UsuarioSessao 4b890fdd; Password: [PROTECTED]; Authenticated: true; Details: null; Not any Authorities Granted, controlePaginasPesquisador br.gov.saude.plataformabrasil.visao.ControlePaginasPesquisador 18d85e19 = @, = 5 org.ajax4jsf.application.AjaxStateManager.view_sequence serialized = false}}} globalTransaction = null, erase = false}}+
According to the log, this error is caused by the following class: org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestWrapper, which is not serialized, but I can't figure out for what reason there is an object in the session which have an instance of that class. We are using JSF, with security implemented by springSecurity. The class in the error report is the control class of the component which extends the control class of the servlet and we do not access it directly.
Can anyone help me? thanks.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/630143#630143]
Start a new discussion in Clustering Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 5 months
[jBPM Development] - Bug : Getting NullPointerException when getting the ProcessInstance p = ksession.getProcessInstance(id)
by uvijayreddy657
uvijayreddy657 [http://community.jboss.org/people/uvijayreddy657] created the discussion
"Bug : Getting NullPointerException when getting the ProcessInstance p = ksession.getProcessInstance(id)"
To view the discussion, visit: http://community.jboss.org/message/629203#629203
--------------------------------------------------------------
Below is the stacktrace:
java.lang.NullPointerException
at org.jbpm.process.instance.impl.ProcessInstanceImpl.setProcess(ProcessInstanceImpl.java:61)
at org.jbpm.marshalling.impl.AbstractProcessInstanceMarshaller.readProcessInstance(AbstractProcessInstanceMarshaller.java:380)
at org.jbpm.persistence.processinstance.ProcessInstanceInfo.getProcessInstance(ProcessInstanceInfo.java:133)
at org.jbpm.persistence.processinstance.JPAProcessInstanceManager.getProcessInstance(JPAProcessInstanceManager.java:64)
at org.jbpm.process.instance.ProcessRuntimeImpl.getProcessInstance(ProcessRuntimeImpl.java:190)
at org.drools.common.AbstractWorkingMemory.getProcessInstance(AbstractWorkingMemory.java:1113)
at org.drools.impl.StatefulKnowledgeSessionImpl.getProcessInstance(StatefulKnowledgeSessionImpl.java:283)
at org.drools.command.runtime.process.GetProcessInstanceCommand.execute(GetProcessInstanceCommand.java:48)
at org.drools.command.runtime.process.GetProcessInstanceCommand.execute(GetProcessInstanceCommand.java:25)
at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:292)
at org.drools.command.impl.CommandBasedStatefulKnowledgeSession.getProcessInstance(CommandBasedStatefulKnowledgeSession.java:124)
at com.emirates.sds.workflow.bpmn.engine.CWFEngine.getProcessInstance(CWFEngine.java:225)
at com.emirates.sds.workflow.mbean.CWorkflowDesignerMBean.getAssignedTasks(CWorkflowDesignerMBean.java:739)
at com.emirates.sds.workflow.mbean.CWorkflowDesignerMBean.getTasks(CWorkflowDesignerMBean.java:1217)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:62)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54)
at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:71)
at org.apache.el.parser.AstValue.getValue(AstValue.java:118)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:190)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:178)
at javax.faces.component.UIData.getValue(UIData.java:554)
at org.ajax4jsf.component.UIDataAdaptorBase.getValue(UIDataAdaptorBase.java:1647)
at org.ajax4jsf.component.SequenceDataAdaptor.getDataModel(SequenceDataAdaptor.java:65)
at org.richfaces.component.UIExtendedDataTable.resetDataModel(UIExtendedDataTable.java:390)
at org.ajax4jsf.component.UIDataAdaptorBase.beforeRenderResponse(UIDataAdaptorBase.java:1656)
at org.richfaces.component.UIExtendedDataTable.beforeRenderResponse(UIExtendedDataTable.java:417)
at org.ajax4jsf.component.RenderPhaseUIDataAdaptorVisitor.beforeComponent(RenderPhaseUIDataAdaptorVisitor.java:44)
at org.richfaces.event.RenderPhaseComponentListener.processComponents(RenderPhaseComponentListener.java:47)
at org.richfaces.event.RenderPhaseComponentListener.processComponents(RenderPhaseComponentListener.java:55)
at org.richfaces.event.RenderPhaseComponentListener.processComponents(RenderPhaseComponentListener.java:55)
at org.richfaces.event.RenderPhaseComponentListener.processComponents(RenderPhaseComponentListener.java:55)
at org.richfaces.event.RenderPhaseComponentListener.beforePhase(RenderPhaseComponentListener.java:71)
at org.ajax4jsf.component.AjaxViewRoot.processPhaseListeners(AjaxViewRoot.java:188)
at org.ajax4jsf.component.AjaxViewRoot.encodeBegin(AjaxViewRoot.java:510)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1641)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:117)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:135)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:309)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:349)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/629203#629203]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 6 months