Monday, January 22, 2007

Scaling MySpace This fascinating article on the frantic attempts to keep MySpace functioning while its user population exploded may explain why it has been subject to quite a few security issues [Yep those are five different links to five different major security issues found in MySpace] 10:37:53 PM    comment []

XACML PEP Support Always a man for straight questions and straight answers, James McGovern asks: To date, industry analysts have covered security specifications in terms of security products that implement them. I would like to start of by asking what would it take for Anne Thomas Manes and some of the other Burton Group leads to start asking every single vendor they interact with, when they plan on building into their product the XACML PEP specification? Of course, I would love for future Burton Group research to answer this question in writing in upcoming reports with the BPM, DRM, ERP, ESB and ECM domains up first. http://duckdown.blogspot.com/200 7/01/authorization-management-and-identity.html Gerry Gebel also asks about the use of XACML for authorization We've used the XACML PEP/PDP model for some time now. But, I can see the vendor rationale for not implementing it. If the "Security Glue" you use is proprietary, then it's frankly more difficult to throw out your product, and you become a "necessary evil" (as I've heard one or two security products called in the past). Here is now we implement this. If you install Vordel's products, you (of course) get online help. This includes tutorials for many things, such as linking up your security enforcement (PEP side) with your existing security infrastructure (PDP side). Here is a list of the tutorials available, which gives you an idea of some of the connectors we have to SiteMinder, Tivoli Access Manager, etc etc. As you can see, the screenshot is not exchaustive. We're proud of the fact that when you deploy Vordel's products, you are not locked into any one security stack, you can interop with the security and identity management which sits around Vordel, whether we are providing a perimeter XML Gateway or internal Web Services management. So, we're interested in the last one there. We are requesting a SAML assertion from a PDP, using the AuthorizationDecisionQuery message from the XACML specification. Here is the tutorial for configuring this in Vordel's products [this comes from the VordelSecure documentation: VordelSecure is an XML Gateway product which can be deployed on the perimeter or internally in the network for fine-grained AuthZ]. Note that the connections from the Vordel PEP to the SAML PDPs can be duplicated for redundancy, and prioritized also. This is a big advantage XACML gives you. Your AuthZ requests suddenly are XML messages which can be routed, logged, monitored, and managed using standards-based infrastructure. I put this in bold type because it really is a big deal. AuthZ requests are no longer some piece of invisible "internal security plumbing". It means you can bring XML infrastructure (such as Vordel's :-) ) to bear on it. Vordel has had XACML PEP support for four years now. Along with Allan MacPhee from Entrust, I've written an ISTR paper about our joint rollout for a large telecoms customer where Vordel acts as the XACML PEP and Entrust acts as the XACML PDP. [to read it, go to http://dx.doi.org and insert the following document ID: doi:10.1016/j.istr.2005.02.002]. Before this customer went live, I can tell you that they tested every aspect of the PEP/PDP interchange, including pulling the plugs from machines and ensuring that Vordel's products would detect missing PDPs, would prioritize PDPs, perform load-balancing, and failover. As a telco, the customer had a special interest in having no single point of failure and in ensuring high throughput and low latency. Anyway, here is the Vordel product tutorial showing the PEP support which James asks about in his question: ------------------------------------------------------------------------------------------------ SAML PDP Authorization Overview VordelSecure can request an authorization decision from a SAML (Security Assertion Markup Language) PDP (Policy Decision Point) for an authenticated client using the SAML Protocol (SAMLP). In such cases, VordelSecure presents evidence to the PDP in the form of some user credentials, such as the Distinguished Name of a client's X.509 certificate. The PDP decides whether or not the user is authorized to access the requested resource. It then creates an authorization assertion, signs it, and returns it to VordelSecure in a SAML Protocol response. VordelSecure can then perform a number of checks on the response, such as validating the PDP's signature and certificate, and examining the actual assertion itself. It can also insert the SAML authorization assertion into the message for consumption by a downstream Web Service. The following screenshot shows the SAML PDP Authorization screen. Request This section describes how VordelSecure should package the SAMLP request before sending it to the SAML PDP. It is possible to configure a group of SAML PDPs to which VordelSecure will connect in a round-robin fashion if one or more of the PDPs is unavailable. URL groups can be configured by selecting the Add and/or Edit buttons. In both cases, the following dialog is displayed:   SAML PDPs will be used according to the priorities assigned to them. So, for example, let's assume there are two "High" priority URLs, one "Medium" URL, and a single "Low" URL configured. Assuming VordelSecure can successfully connect to the two "High" priority URLs, it will alternate requests between these two URLs only. The other group URLs will not be used at all. If, however, bith of the "High" priority URLs become unavailable, VordelSecure will then try to use the "Medium" priority URL, and only if this fails will the "Low" priority URL be used. So, in general, VordelSecure will attempt to round-robin requests over URLs of the same priority, but will use higher priority URLs before lower priority ones. When a new URL is added to the group it is automatically given the highest priority. Priorites can then be changed by selecting the URL and clicking the Up and Down buttons. Individual PDPs can be added and edited by selecting the URL from the table and clicking on the Add and Edit buttons respectively, both of which display the following dialog:     The following fields should be completed: URL: Enter the full URL of the SAML PDP server. Timeout: Specify the timeout in seconds for connections to the PDP. Retry After: Whenever a PDP becomes unavailable for whatever reason (maintenance, for example), no attempt will be made to connect to that server until the time specified here has elapsed. In other words, once a connection failure has been detected, the next connection to that URL will be made after this amount of time. Username: If the specified PDP requires clients to authenticate to it over 2-way SSL, a Vordel User must be selected here for authentication. This user must have been assigned the "Use for client authentication" privilege. Host/IP: If the PDP sits behind a proxy server, details of the proxy must be entered here. Enter the host name or IP address of the proxy server. Port: Enter the port on which the proxy server is listening. Having configured a group of SAML PDPs to connect to, the following general fields must be completed: SOAPAction: Enter the SOAP Action required to send SAML Protocol requests to the PDP. Click the Use Default button to use the following default SOAP Action as specified by the SAML Protocol: http://www.oasis-open.org/committees/security SAML Version: Select the SAML version to use in the SAMLP request. Drift Time: The SAMLP request to the PDP is timestamped by VordelSecure. To account for differences in the times on the machines running VordelSecure and the SAML PDP the time specified here will be subtracted from the time at which VordelSecure generates the SAMLP request. SOAP Actor/Role: The SAML authorization assertion received from the PDP can be inserted into the downstream SOAP message. The assertion will be inserted into the WS-Security block identified by the SOAP actor/role entered here. If no actor/role is selected here, the assertion will not be added to the message. SAML Attributes Tab This tab is used to specify the subject of the SAMLP request. Subject Attribute: Specify the message attribute that contains the subject of the SAMLP request. Subject Format: Specify the format of the subject id using one of the default formats. There is no need to select a format here if the Subject Attribute above is set to authentication.subject.id, which is the default. Subject Confirmation Tab The settings on the Confirmation Method tab determines how the block of the SAML assertion is generated. When the assertion is consumed by a downstream Web Service, the information contained withing the block can be used to authenticate either the end-user that authenticated to VordelSecure, or the issuer of the assertion, depending on what is configured. A typical block is show below: urn:oasis:names:tc:SAML:1.0:cm:holder-of-key CN=vordel MIICmzCCAY ...... mB9CJEw4Q= The following fields must be configured on the Subject Confirmation tab: Method: The value selected here determines the value of the element. The following table shows the available methods, their meanings, and their respective values in the element: Method Meaning Value Holder Of Key A is inserted into the SAMLP request. The will contain a section with the cert of the user selected to sign the SAMLP request. The user selected to sign the SAMLP request must be the authenticated subject, i.e. "authentication.subject.id". Check the Certificate is included if the signer's certificate is to be included in the SubjectConfimration block. Alternatively, select the Only key name is included radio button if only the key name is to be included. Select the user whose private key will be used to sign part of the message in the User Name dropdown on the Sign Request tab. urn:oasis:names:tc:SAML:1.0:cm:holder-of-key Bearer A is inserted into the SAMLP request. urn:oasis:names:tc:SAML:1.0:cm:bearer Transmit Subject Cert A is inserted into the SAMLP request. The will contain a section with the cert of the authenticated user, i.e. the "authentication.cert". This is a Vordel-defined subject confirmation mechanism implemented to facilitate the passing of the subject's certificate to the SMAL PDP. The user signing the SAMLP request does NOT have to be the authenticated subject. Check the Certificate is included if the subject's certificate is to be included in the SubjectConfimration block. Alternatively, select the Only key name is included radio button if only the key name is to be included. urn:vordel:transmit-subject-cert SAML Artifact A is inserted into the SAMLP request. urn:oasis:names:tc:SAML:1.0:cm:artifact Sender Vouches A is inserted into the SAMLP request. The SAMLP request must be signed by a Vordel user. urn:oasis:names:tc:SAML:1.0:cm:bearer If the Method field is left blank, no block is inserted into the assertion. Sign Request Tab If the SAMLP request is to be signed, select the name of the Vordel user that is to sign the request from the User Name field. Evidence The SAML Protocol stipulates that proof of identity in the form of a SAML authentication assertion must be presented to the SAML PDP as part of the SAMLP request. VordelSecure can either use an existing SAML authentication assertion that is already present in the message, or it can generated on based on the user that autenticated to it. Select the Use SAML Assertion in message option to include an existing assertion in the SAMLP request. Specify the actor/role of the WS-Security block where the assertion can be found. Alternatively, select the Create SAML Assertion from authenticated client radio button in order to generate a new authentication assertion for inclusion in the SAMLP request. The newly generated assertion can be signed by a Vordel User by selecting that user from the User Name field. The Drift Time specified here will be subtracted from the time at which VordelSecure generates the authentication assertion. This is to account for any possible difference in the times of the machines hosting the SAML PDP and VordelSecure. Response VordelSecure can be configured to perform a number of checks on the SAML Protocol response from the PDP by examining the contents of various key elements within the authorization assertion. The following screenshot shows the checks that can be performed on the SAMLP response:   Optional Settings The authorization assertion can be checked to ensure that the authorized subject matches a specified value, and that the resource specified in the assertion matches the one entered here. VordelSecure can verify that the subject in the SAML assertion (i.e. the ) matches one of the following. Select the corresponding radio button. The subject of the authentication filter. The following value, e.g. "CN=sample, O=Vordel, C=ie" Neither of the above. VordelSecure examines the tag inside the SAML authorization assertion. It is possible to enter a value for the resource in the Resource field. VordelSecure will then compare the in the assertion to this value. The filter will pass if the value matches the value entered in the Resource field. It is possible to enter wildcards representing message attributes in this field. Wildcards have the following format: ${message.attribute} So, for example, to specify the original path on which the request was received by VordelSecure as the resource, enter the following wildcard: ${http.request.uri} References SAML Specification XACML Specification 2:31:09 PM    comment []

When Enterprise SOAs meet the cloud Joe McKendrick cites a recent McKinsey & Company report which says that "nearly half of CIOs (48 percent) are planning to open their SOAs “to the cloud” in 2007 — the cloud being “where their current and potential trading partners are.” He goes on to say compare SOA with it's cousin, Software as a Service (SaaS), saying that "the business case for SOA may become very similar to that of SaaS — avoiding large upfront investments in systems and software in favor of more incremental costs. SOA is SaaS behind the firewall, and will blend with SaaS in the cloud. It's about infrastructure, or avoiding infrastructure." Phil Wainewright also runs with this idea and says that: "Once your software becomes a service in the cloud, it opens up the potential to link it up with other services that are out there. For many vendors and users this is still a barely dawning realization, but it's of fundamental importance. In many ways, the Internet cloud is one great global SOA — still very rudimentary in many ways, but flexible enough to accommodate different levels of sophistication, and evolving fast." From Vordel's vantage point, we've always see a high number of internal SOAs being exposed across the firewall (well, across the XML Gateway in our case). But, in most cases they are not being exposed to the entire "cloud", but to partners, suppliers, and customers. Todd Biske makes this same point - saying "Companies need to do business. Often times, that business requires interaction between two or more companies. Can SOA help in that interaction? Absolutely.", but adds: "On the flipside, however, is SOA really opening up new interactions between businesses that previously didn’t exist, or is it simply allowing those interactions to be more efficient?" Many industry verticals routinely do business through partners and intermediaries, and so are great candidates for this "opening of SOA's to the cloud" (where the "cloud" is composed of their partners, suppliers, and customers). It's interesting to read about some case studies of the SOA being opened up in a secure and managed manner (e.g. here is one about a large insurance company which opens up its SOA to its agents/brokers). The other angle here, of course, is what Joe McKendrick calls the "outside in" aspect. This involves corporate usage of so-called "Web 2.0" style Web Services. I am giving a talk at the RSA Conference on security for Web 2.0 Web Services next month, and let me tell you, there are some serious security issues there [although, interestingly, Microsoft's Windows Update and IE7 has been quietly addressing some of them recently]. I'll be covering this angle at RSA. Dave Linthicum sums up the requirements for managing these "outside in" services well: First, accept the notion that it's okay to leverage services that are hosted on the Internet as part of your SOA, and it's okay to expose services to systems you don't control. Normal security management needs to apply, of course. The largest issue, unfortunately, is acceptance. The technology is not that complex, many of the political and people issues are. Second, create a strategy for the consumption and management of outside-in services, as well as the exposure of inside-out services, including how you'll deal with semantic management, security, transactions, etc. Same good SOA requirements work applies here. http://weblog.infoworld.com/realworldsoa/archives/2007/01/more_validation.html I'd argue that most of the groundwork for this has been done by vendors such as Vordel which have successfully opened up SOA's to the cloud in a managed, secure, manner for the past 4 years. P.S. You know what all this reminds me of? Remember when business would spend a lot of time and money on ponderous and slow-moving internal PKI projects? And remember then that SSL proved to be the simple use case of PKI which took off in the "cloud" like wild-fire and enabled a huge amount of innovation and commerce? Then remember that many of the internal PKI projects simply used the "cloud" by using VeriSign certificates? And VeriSign did very well out of this? Well, substitute "SOA" for "PKI" and "REST" for "SSL", and you have the situation with Web Services now. But, who is the VeriSign this time? 8:50:36 AM    comment []