[JBoss JIRA] (RTGOV-59) Enable security on REST services
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/RTGOV-59?page=com.atlassian.jira.plugin.s... ]
Eric Wittmann commented on RTGOV-59:
------------------------------------
After looking into this a bit I'm not too sure how to proceed. The Overlord RTGov REST services are invoked from their respective gadgets via the gadget IO layer provided by the shindig gadget server. Here's how this works:
1) The shindig server provides container.js to the host page in gadget-web
2) The container.js includes a "makeRequest" function in gadgets.io (a javascript function for making JSON REST calls)
3) A gadget invokes a REST endpoint by calling gadgets.io.makeRequest(), passing the args and the URL of the REST service
4) The javascript function invokes a servlet found in gadget-server (MakeRequestServlet)
5) The makeRequest servlet in turn invokes the actual REST endpoint (e.g. in overlord-rtgov)
6) The REST endpoint responds with JSON
7) The makeRequest receives the JSON data and wraps it into a response object, returning it to the client-side gadgets.io.makeRequest() handler
8) The gagdet's callback is invoked with the response payload
Security considerations are many and varied. First note that user logins will occur on the gadget-web context. This is where SSO, for example, is configured (so that users must login before accessing the gadget UI).
The container.js javascript is served out of the gadget-server web context, along with the data services (MakeRequestServlet) provided by it.
The gadgets themselves are served out of yet another context, "gadgets". I don't believe this is relevant, since the gadgets always go through the gadget-server's IO layer.
Additionally, the Overlord RTGov REST endpoints exist in the overlord-rtgov web context.
Ultimately we want to secure the REST services in overlord-rtgov in such a way that the MakeRequestServlet in the gadget-server web context can securely invoke them.
Also note that currently the gadget-server context is not secured, which implies that its endpoints could be invoked directly (e.g. makeRequest). It's likely that this also needs to be addressed.
> Enable security on REST services
> --------------------------------
>
> Key: RTGOV-59
> URL: https://issues.jboss.org/browse/RTGOV-59
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Reporter: Gary Brown
> Assignee: Eric Wittmann
> Priority: Critical
> Fix For: 1.0.0.Final
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (RTGOV-181) Associating separate Activity Units with SOA and BPM related events
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-181?page=com.atlassian.jira.plugin.... ]
Gary Brown resolved RTGOV-181.
------------------------------
Resolution: Done
> Associating separate Activity Units with SOA and BPM related events
> -------------------------------------------------------------------
>
> Key: RTGOV-181
> URL: https://issues.jboss.org/browse/RTGOV-181
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Reporter: Gary Brown
> Assignee: Gary Brown
> Priority: Critical
> Fix For: 1.0.0.Final
>
>
> Due to the way activity collector implicitly associates activity events based on threads, the SOA related (interaction) events are stored on one activity unit, while the BPM (e.g. BPEL) related events generated by the process executing within the service, are stored in a separate activity unit(s).
> We need a way in which to associate these activity units, to reflect the relationship between the activities.
> One possible solution is to register an activity when a BPM related job is added to a job queue, and then similarly when it is retrieved. This may require a change to the riftsaw engine to generate this type of event.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months