What's in a Composite API Platform?

Intel recently released what we call a composite API platform with our new API Manager product. What exactly do we mean by this?

A composite platform is a single platform for API management that handles both Public (sometimes called “Open”) APIs and Enterprise APIs. It’s composite because it exhibits both the cost savings of “cloud” through a multi-tenant SaaS partner portal coupled with the control of on-premises gateway for traffic management. Like a composite material, the mingling of two or more constituents gives the final solution different properties not found in either alone.

For a public or open API it’s important to have developers interact in a shared manner, generally done through a public SaaS partner management portal. True multi-tenant SaaS offerings gives the Enterprise cost advantages, as the partner management piece is akin to running a website for potentially thousands of developers.Running a successful website means people, resources, archival and a higher cost of ownership.

Further, Multi-tenant SaaS means developers may be using more than just your API as they may also be finding other APIs they are interested in advertised from other tenants. This is a good thing as these are the caliber of developers you want. After all, experienced developers can bring more to the table – they may even come up with an awesome app that mixes your data with a partner’s in a new way.

As flashy as the cloud is, not all Enterprises can risk complete movement to a public cloud environment, especially for security and compliance. The set of applications bound to the enterprise are sometimes called “gravity bound”, as they are part of an information system tied to a core business processes or cannot be outsourced due to compliance, privacy or security issues.

How do these applications gain the benefits of the API economy? What if you want to build an mobile app or partner app that interacts with a mainframe or legacy system? How do you ensure compliance for API traffic that involves sensitive information? What about security?

For these types of large scale environments, the Enterprise has good reasons to buy and own some of the components used to expose the API. Overall, the composite API platform really mixes the concepts of Public APIs and Enterprise APIs together.

All APIs are really Enterprise APIs, its the manner in which they are exposed and their purpose that labels then Public or “Enterprise”, but in reality they both support an Enterprise’s API strategy and we might argue that the most successful enterprises will actually have both.

What You Need to Know about API Security

Since the growth of APIs “hockey-sticked” around 2005, the proliferation of web-based APIs has spanned every industry and vertical from e-commerce to map services to enterprise. APIs like that of Twitter, Amazon, and Netflix garner billions of API calls every day, and these represent just a few of the more visible.  With this rapid growth, on the order of 300-400 new APIs arriving each month, security is an ever-increasing concern.  Enterprise focused, SaaS based APIs are among the fastest growing segments, and in light of this, securing company assets and Data Loss Prevention are paramount.  The perimeter of enterprise networks has become amorphous as workflows increasingly leverage platforms and applications beyond the firewall.  So what does that mean for your organization’s security?

Attend our May 10th webinar featuring Intel, McAfee, and tech analyst & CTO, Dan Woods for an advanced perspective on what you should do to ensure API Security, specifically as related to Authentication, DLP, and Validation Controls.

 For more information about Intel Expressway Service Gateway — with free webinars, tutorials and expert blogs on securely exposing Web Services in the Cloud, please visit us at: www.intel.com/go/identity

Webinar: Applying Strong Authentication and Data Loss Prevention to Collaborative File Sharing (April 26)

Join us for what will be a very informative webinar on Applying Strong Authentication and Data Loss Prevention to Collaborative File Sharing

April 26th 2012 – Time: 10:00 AM PDT, 1:00 PM EDT

> Register Now

Employees love the convenience and utility of collaborative file sharing applications like Box. Sharing contracts, graphics/video files, or other corporate content using a cloud-based service empowers users to share information directly with external partners-outside traditional enterprise security controls.

While you want to encourage productivity, you also need a strategy that addresses how you’re going to control access to file sharing applications and inspect data before it leaves the enterprise.

In this webinar Intel, McAfee and Box join forces to discuss how your sensitive content can be protected throughout the collaboration life cycle—from access and upload to download and distribution.

You will learn:

  • Overview of typical file sharing use cases and workflows
  • Streamlining access for users
  • Tying federated authentication to corporate ID stores
  • Adding 2nd factor strong authentication for sensitive document security
  • Blocking sensitive files from upload
  • On-prem, 100% in the cloud, and hybrid SaaS access options

As a bonus, all attendees will be eligible to receive a free enterprise trial account from Box.

 

 

 

 

 

For additional information, please visit www.intel.com/go/identity

 

 

Our SaaS CloudSSO – par excellence

Essentially that is what it is. Recently we announced our Force.com based Cloud SSO solution. What is unique about this is that we are the first (and as of now the ONLY) solution that will allow Force.com user identities to be federated not only across Force.com applications, but also across other cloud providers as well.

We provide Identity for the cloud in the cloud – now that is different, isn’t it?

I know, I know… there are about half of a dozen vendors that claim to provide a Cloud SSO solution. So why are we different or better than the others?

We provide a fusion, bringing together the best of McAfee and Intel.   We bring years of advanced security research ,  our multi-tenant offering cloud security suite from McAfee, coupled with Intel’s Identity offering that includes SSO, hardened provisioning/de-provisioning and an escalated authentication (OTP) solution.

Everyone knows that salesforce.com is all about the cloud and SaaS, right? But once you set up your users/ identities in the Force.com platform it can be only used there. If you need to setup another SaaS application then your administrator needs to setup the user base all over again. Even though there are tools available to make this process easier it is still a chore. Imagine if you could have the power to set up the identities and policies once and run forever. If your users have to remember only ONE password then you could enforce the passwords to be very strong. This would not only reduce the security risk (imagine a SaaS application having a weak password… what can be more dangerous than that) but it could also help with eliminating a lot of help desk password reset calls from frustrated users.

One pivotal and unspoken benefit is the  increase in productivity where a user can seamlessly navigate between applications.

Our solution also includes a hardened, proven provisioning/ de-provisioning which takes care of syncing identities across applications and across multiple cloud providers. And there is also a built-in escalated authentication of identity using a second form factor which comes in handy when someone tries to use sensitive applications. Our OTP (One Time Password) solution allows the users to provide the second factor (of what you have in addition to what you know).

If you missed our recent announcement about the beta release at RSA check it out here.

http://www.networkworld.com/news/2012/022712-intel-cloud-sso-256621.html

http://software.intel.com/en-us/blogs/2012/02/27/introducing-cloud-idaas-intel-cloud-sso/

For more details check us out IntelCloudSSO.com

Andy Thurai — Chief Architect & CTO, Application Security and Identity Products, Intel. Andy Thurai is Chief Architect and CTO of Application Security and Identity Products with Intel, where he is responsible for architecting SOA, Cloud, Governance, Security, and Identity solutions for their major corporate customers. In his role he is responsible for helping Intel/McAfee field  and technical teams and customer executives. Prior to this role he has held technology and architecture leadership and executive positions with L-1 Identity Solutions, IBM Datapower, BMC, CSC, and Nortel. His interests and expertise include Cloud, SOA, identity management, security, governance, and SaaS. He holds a degree in Electrical and Electronics engineering and has over 20+ years of IT experience.

 

 

 

Cloud Access 360 2.0 version released

We’re happy to announce general availability of Intel Expressway Cloud Access 360 (ECA 360) 2.0 release. This new release adds a range of exciting new features designed to simplify and improve our customers ability to manage user’s access to popular cloud applications. Key new features and benefits include:

Built-in SSO portal

An out-of-box SSO portal is available with the product that can run standalone or embedded inside
existing portals such as Sharepoint. Users authenticate once to the portal
and enjoy convenient, seamless SSO access to any authorized cloud app. As SSO
portals expose keys to the kingdom, login to it can be protected with 2-factor
authentication using mobile based One Time Password (OTP) offered through the
bundled OTP module.

More connectors

New out-of-the-box connectors are  available for popular cloud apps such as Microsoft Office365, Cisco WebEx,
Box.Net, Service-Now, SugarCRM, Zoho, EchoSign, Schoology, and Joomla.

Transparent HTTP
form-based SSO

Not every SaaS application
support SAML based federation today. This feature allows customers to bring non-SAML
apps into the SSO portal providing convenient, seamless access to users and
enabling IT to achieve better control and visibility on SaaS application
usage. This is achieved by enabling users to register user ID and password
once on a web site and capturing the data for transparent SSO the next time the
user accesses the app. The process is transparent to the user as they don’t even
see the log-on screen.

Salesforce as an Identity
Provider

Instead of authenticating the user against Active Directory, ECA 360 allows the user to be authenticated using
Facebook, Google, Yahoo, and any OpenID provider. With this release, Salesforce
as an Identity Provider has been added to this list. This enables our customers
to let its contractor, partner and affiliate users to login into ECA 360 SSO
portal using Salesforce credentials and further access cloud applications
they are authorized to access.

Enterprise-class
scalability

ECA 360′s ability to support more than 10,000 concurrent user authentications has been tested and
verified.

Higher performance and
availability

ECA 360 administrators can now run multiple instances in a clustered environment.

Other improvements

These include: support for short URL entry in a mobile browser, new
compliance reports, and various bug fixes.

To learn more about the new and improved ECA 360 v2, please visit our web site at www.intel.com/go/identity.

Forrester Cloud Jam Session DAY 2: The Authoritative ID Store Is Dead – How the Cloud Changes Provisioning

Join us this Thursday, July 28, 2011 at 1PM Pacific (replay will be available after initial broadcast) as Andras Cser, Principal Analyst, Forrester and Vikas Jain, Director of Product Management, Intel Cloud Identity & Security shed light on how account provisioning should be added to deliver enterprise class secure cloud access implementations.

Register here:

Forrester Cloud Jam Session Day 2

As IdM in the Enterprise evolved, all software programs from operating systems, middleware, and applications as well as networking programs such as VPN converged on integrating with a single authoritative ID store based on LDAP protocol. The cloud is changing this as every SaaS application tries to maintain account information about users leading to emergence of multiple identity silos. On the other hand, many SaaS providers are eyeing identities they manage as business assets to create stickiness with their products and getting in the race of becoming authoritative identity provider themselves. These couple of scenarios are leading to new challenges to solve in the identity provisioning and synchronization space.

Achieving unified control, visibility, and compliance for SaaS applications

Technical Information Security Policy

The first step to delivering the right control and visibility architecture for SaaS is to formalize the enterprise’s goal in a Technical Security Policy. The security policy lifecycle begins with policy creation and development. The Security architect must collaborate with policy authors, management, development and operations to define specific technical policies that will enforce the security architecture decisions. These policies may govern issues such as:

  • Define allowable & non-allowable usage
  • Security token types & issuers
  • Integrity requirements
  • Logging & monitoring requirements
  • Access control protocols
  • Message and Channel Encryption

These are a subset of some of the concerns that the Technical Security Policy must address to govern access and visibility to SaaS applications. Every organization has some type of Information Security Policy, these are typically hundreds of pages long, but are written at a high level and do not contain specific technical guidance such as the above list. The Technical Security Policy closes out this gap. Some standards such as WS-SecurityPolicy have emerged in this space and are worth studying to understand the level of granularity that can be expressed.

As a rule of thumb, the Technical Security Policy should include allowable and no-allowable usage for the application’s Attack Surface. For many SaaS applications, the Web Services Attack Surface is comprised of the application’s Data (such as XML), Methods (such as SOAP, and URI), and Communication channel (such as HTTP). In other systems such as Mobile applications the Attack surface could also include SMS, Geolocation, and other smartphone services.

The Technical Security Policy is likely to be highly contextualized based on each deployment type, and to cover a wide array of different deployment integration patterns – from network security to app security to identity management. This approach is good from a design standpoint because it allows the Security Architect to be precise and specific with guidance. It’s also problematic because the audit, review, execution and lifecycle management can be challenging.

Closing Out Technical Gaps with a Security Gateway

The Security Gateway pattern fills this gap by providing an execution environment to enforce the Security policies. Sure, each endpoint can be wired up to validate SAML assertions and enforce message integrity, but for a system with numerous endpoints, manageability and assurance quickly becomes a limiting factor to this approach. The Security Gateway pattern mediates communication to and from SaaS application providers and gives the Security Architect the ability to ensure that technical security policy is being enforced. Further, the Security Architect now has a location to manage and deploy any changes to the Security Policies. Say that a SaaS provider is initially only supporting weak username/password combination for access, but that the SaaS provider is working on an upgrade to support SAML. Instead of re-wiring all endpoints, the Security Architect can wire on SAML on the Security Gateway once the SaaS provider is operational with SAML.

The SaaS provider is home to some of the enterprise’s most important data and functionality such as customer data. The Security architect will often seek to record any CRUD access to the critical SaaS functionality and data, and to accomplish the Gateway chokepoint for inbound and outbound access is essential. Simply monitoring open and close network connection won’t cut it, when message semantics are needed to determine who did what where in the SaaS application.

identity_token_usage.jpg

The Gateway formalizes the security architecture’s roles and responsibilities with the SaaS Cloud provider. The Gateway serves to enforce the policy, making runtime access control decisions, provide a place for auditors to review the controls for compliance purposes, and for the administrators to manage the system over its lifecycle. This division of roles and responsibilities gives the enterprise the ability to retain a modicum of control while still leveraging Cloud applications for their benefits.

gunnar1.jpg

Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchanges, healthcare, manufacturer, and federal/Gov systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, an Associate Editor for Information Security Bulletin, a contributor to the SEI and DHS Build Security In portal on software security, and an in-demand speaker at security conferences. He blogs at http://1raindrop.typepad.com.

Follow

Get every new post delivered to your Inbox.

Join 137 other followers