|
* Click anywhere on the image to go back *
In distributed-system scenarios such as the ones we address in BREIN, the main security problem is cross-organizational authorization. Most identity and access systems available today provide flexible solutions for authorization-related problems within the boundaries of a single organization. Still, IT professionals who need security solutions for cross-organizational collaboration typically need to develop their own custom solutions.
In the BREIN project, we extend the security work we did in former projects, such as TrustCoM, MOSQUITO, NextGRID and MYCAREVENT. In these projects, our security work addressed research problems such as human-supported federation establishment and enactment, VO-centric identity and claims management, and authorization for cross-organizational service invocation. While we gained many insights into the VO security area, we identified a couple of issues that needed further research: One open question is how to leverage the human user for context provisioning, such as why a particular service interaction happens, and subsequently utilizing that context for security decisions. The second broader issue for which we need a solution is the access management for re-sources located outside of our own organizational trust boundary. The third topic is related to the support for claims-based security in protocols that do not support WS-Security, such as MTOM-based streaming.
In the BREIN architecture, security-related implementation artefacts are located at various places and layers, so that we can scale the flexibility of the solution depending on the concrete security requirements of the respective scenario. For example, it is clear that cross-organizational message exchanges always have to be integrity and confidentiality protected. Depending on the capabilities and features of the web services stacks of both clients and application services, we either have the end-nodes taking care of handling the cross-organizational security themselves, or we factor big parts of that responsibility into infrastructure components such as the gateway service. For example, if a web services-based client application cannot encrypt and sign SOAP messages using the appropriate cross-organizational security tokens, then that responsibility is handled by the gateway service which is sitting in the message path, on behalf of the client.
|
