Arch2Arch > Community > Arch2Arch Media Center > Webinars

---

Webinar: The Implications of a Service-Oriented Architecture (SOA) on Security

Date: This event took place on September 07 2005

Presentation:

Recording: https://attewc.webex.com/attewc/onstage/framesets/viewrecording1.php?EventID=369113804

Description:

Security is often viewed as a gating item barring successful deployment of an SOA. Traditional security technologies are simply not enough to address loosely coupled Web services communicating with SOAP messages over an HTTPS connection. This talk will provide an overview of the security requirements and technologies necessary for successful SOA deployment and will discuss how BEA's solutions assist an organization in achieving their SOA objectives. The talk will also cover emerging security standards related to this effort, such as WS-Security and SAML, and their importance to achieving success.

Q&A:

1) Q: In the slide about Infrastructure Evolution; is it reliable to have a Tuxedo Client with web app?

A: In http://e-docs.bea.com/tuxedo/tux90/overview/webaccess.htm you will find more information about the different techniques that you can use to provide access to a TUXEDO application from a Web application. The reliability depends on the configuration and technique that you use.

2) Q: Is it possible to easily integrate AquaLogic with existing UDDI and web services mgmt software like AmberPoint and Forum Systems?

A: Aqualogic will provide an integrated UDDI-compliant registry; you can find more information at http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/service_registry/ . With this product, you will be able to integrate other federated UDDI registries into a multi-level hierarchy. BEA and AmberPoint announced a partnership by which AmberPoint will be integrating their solutions with our AquaLogic product family. BEA also encourages other companies and partners to integrate with its AquaLogic Service Infrastructure.

3) Q: The extended authorization is useful based on context but how would apps that have their own context (e.g. a non WLS resources - a user is accessing a value from a DB that should only be displayed based on role), invoke a custom authorization provider?

A: You can use the AquaLogic Enterprise Security (ALES) Java Services Security Module (SSM) to secure your custom application and to define how your application resources look like. The exact steps for using the Java SSM are detailed here http://e-docs.bea.com/wles/docs42/programmersguide/progmmg.html#1053532. In your example above, you can define a policy using a user role and a resource (it may the DB value); change your application to call the “isAccessAllowed” Java SSM method before returning the value to the user – this method returns “yes” or “no” based on the evaluation of the policy. You do not need to define a custom authorization provider with this approach.

4) Q: What examples/solutions/approaches are available in WLS 9 when integrating SSO with external partners?

A: Assuming that the external partners use Web Services, your best integration approach is to use SAML. WLS 9.0 provides support for SAML 1.1. For more information about using SAML with Web Services, please refer to http://e-docs.bea.com/wls/docs90/webserv/security.html, section "Using Security Assertion Markup Language (SAML) Token for Identity". Note that partners still need to agree upon the nature of the tokens and assertions exchanged.

Presenter:

Juan M. Andrade, Technical Director with the BEA Systems Office of the CTO, is responsible for the overall security product strategy at BEA. He has more than 25 years of experience in distributed systems and he has been influential in the design of the different BEA products. Juan is one of the original architects of the Tuxedo System. He has been working at BEA for the last 9 years.