Big-IP Access Policy Manager (APM) Identity Federation SAML Documentation
As enterprise customers start to accelerate their cloud Software-as-a-Service (SaaS) deployments their IT staff is observing increased help desk calls and user password fatigue issues. F5’s Big-IP Access Policy Manager (APM) product can address these requirements through its support for SAML 2.0 federation services like Identity Provider (IdP) for popular SaaS services such as Office 365, Salesforce etc. Big-IP APM supports both Service Provider (SP)-initiated and IdP-initiated deployments for identity federation to SaaS services as illustrated below User logs on to the Big-IP APM IdP and is directed to the webtop User selects a Salesforce service from the webtop. Big-IP APM may retrieve attributes from the user data store to pass on to the SaaS service provider. Big-IP APM directs the requests to the SaaS service with the SAML assertion and optional attributes via the user browser. User accesses Salesforce SaaS service. Salesforce redirects the user back to the Big-IP APM SAML IdP with SAML request via the user's browser. Big-IP APM prompts the user to logon with the relevant credentials. At this time Big-IP APM may retrieve attributes from the user data store to pass on with the SaaS service provider (SP). Big-IP APM then sends a SAML response to Salesforce with the authentication information and optional attributes via the user's browser for allowing access to the service. Over the years F5 has been extending its support for identity federation including support for SAML 2.0 OASIS standard features and publishing collateral for administrators to easily deploy Big-IP APM IdP services. Below is a consolidated list of documentation which includes the deployment guides to federate against the following SaaS services Office 365 Salesforce Workday Amazon Web Services Concur Service Now Jive Wombat Zendesk Cisco Webex Box Google Apps The deployment guides mentioned below provide details on setting up the following Big-IP APM objects for above mentioned SaaS applications Profiles, AAA server and Virtual Server IdP Configuration SP Connector Configuration Access Policy Setup using Visual Policy Editor iApps to setup the above configuration is also available in the guide* The deployment guides also have pointers on configuring SaaS SP services based on the SaaS provider documentation. While these deployment guides are provided as a quick reference for configuring the above mentioned SaaS applications, Big-IP APM can be used to setup almost any other SaaS applications that support SAML 2.0 OASIS standard. Deployment Guides Configuring the BIG-IP APM as a SAML 2.0 Identity Provider for Common SaaS Applications (For all SaaS applications other than office 365) Configuring the BIG-IP APM as a SAML 2.0 Identity Provider for Microsoft Office 365 Please add comments below should you have any feedback for this documentation or need other APM related documentation. * Production version of APM IdP to Office 365 iApp is available in the Office 365 guide. Beta version of iApp for all other SaaS applications is available here (production version will be released soon)
Microsoft Dynamics 365 Portal SSO
Hi Just wondering if anyone here has successfully setup SAML2.0 federation with Microsoft Dynamics 365 Portals? This document doesn't specifically mention F5, but I dont' see why it wouldn't work. https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-saml2-settings I have created the site settings similar to AzureAD and shibboleth Authentication/SAML2/F5/AssertionConsumerServiceUrl - https://samltrialf5.microsoftcrmportals.com/signin-saml2 Authentication/SAML2/F5/AuthenticationType - https://sts.myidp.com.au/idp/portal Authentication/SAML2/F5/Caption - MyIDP SSO Authentication/SAML2/F5/MetadataAddress - https://sts.myidp.com.au/idp/f5 Authentication/SAML2/F5/ServiceProviderRealm - https://samltrialf5.microsoftcrmportals.com/ When I go to the portal site and click sign in, I can see an external account option of "MyIDP SSO". However when I click on the button I get a HTTP 500 error from Microsoft "We're sorry, but something went wrong" The metadataAddress currently doesn't actually contain the federationMetadata file from the F5, so I plan on hosting that using an iFile and updating that site setting to see if that might be causing the issue. I just wanted to see if anyone here had been successful in federating with D365 Portals? Cheers, Simon
SAML Find Its Cloud Legs
#IAM #cloud #infosec #SAML “When I took office, only high energy physicists had ever heard of what is called the World Wide Web... Now even my cat has it's own page.” - Bill Clinton Despite the slow descent into irrelevance of SOA and its core standards, several of its ancillary standards remain steadfastly alive and in some cases are growing in relevance. In particular, SAML is gaining steam thanks in large part to the explosive adoption of SaaS. SAML (Security Assertion Markup Language), now on its second major version, was most commonly associated with efforts by the Liberty Alliance (long since defunct and absorbed into the Kantara Initiative) to federate authentication and authorization across the web. The "big deal" with SAML was that it was easily supported by the browser. Of course when it was introduced there were few services enterprises felt needed federation with corporate systems and thus despite the energy surrounding the project it was largely ineffective at producing the desired results. Fast forward to today and the situation out there has changed. Enterprises are increasingly invested in SaaS (which is still really just a web application) and are growing more aware of the challenges associated with that investment, particularly around identity, access, and control. Re-enter SAML. This time, with a much better chance of becoming The Standard for federating identity across cloud-deployed applications. WHY SAML? WHY NOW? The appeal remains, in large part, due to its focus on the browser through which most if not all enterprise resources are accessed today. Add in a healthy dose of mobile devices, roaming employees, and new off-premise enterprise services and you've got a recipe for SAML's success. The need for organizations to get a grip on (reassert control over) access and identity management is significant. As we recently learned there are mounting concerns with respect to distributed credentials and unfettered access to corporate applications residing off-premise. SAML 2.0 offers a standards-based, increasingly supported means of accomplishing this feat of wondrous power through a combination of well-defined processes and products (er, services). Salesforce.com: Configuring SAML Settings for Single Sign-On Single sign-on is a process that allows network users to access all authorized network resources without having to log in separately to each resource. Single sign-on allows you to validate usernames and passwords against your corporate user database or other client application rather than having separate user passwords managed by Salesforce. Google: SAML Single Sign-On (SSO) Service for Google Apps Using the SAML model, Google acts as the service provider and provides services such as Gmail and Start Pages. Google partners act as identity providers and control usernames, passwords and other information used to identify, authenticate and authorize users for web applications that Google hosts. The list goes on: Concur, SugarCRM, FedEx, RightScale. This is the tip of the iceberg when it comes to SAML. And it's not just vendors offering support, it's users asking for it, coding it into their applications, demanding it. And why shouldn't they? SAML 2.0 is highly flexible in its ability to provide a standard process through which authentication and authorization to resources can be provided. It provides the process and the payload necessary to unify and federate identity across distributed applications, and it can be easily used in the browser as well as in custom applications. It's a markup language standard transported largely over HTTP. Because it has well defined processes that describe how to federate identity using an SP (Service Provider) and an IdP (Identity Provider) organizations and vendors alike can cleanly implement support either directly or through a third-party provider like Ping Identity, One Login, or SecureAuth. SAML can support mobile devices and APIs as easily as it can traditional browser-based resources. When used by a cloud access broker acting as an access control gateway, SAML can be used to provide single-sign on for both cloud and data center hosted resources. It's really quite a flexible little standard that seems to have finally found its sea legs - if by "sea legs" one means cloud legs.Access Control in the New Mobile, Hybrid World
There is a brave new world dawning for the corporate world. There are many “new norms” – and a gold rush of new opportunities, but also new challenges with which they come – streaking like lightning throughout organizations. The workforce of today and into the future is, and will continue to be mobile. Consider that according to analyst IDC, 37 percent of the worldwide workforce will be mobile by the end of 2015. That’s about 1.3 billion mobile workers, worldwide – not to mention there will be two or more times as many mobile devices as mobile workers! – by the end of this calendar year! Then, consider this: According to Orange Business Services, 55 percent of worldwide business IP traffic will be mobile business Internet traffic by 2018. Mobility is here, and it’s here to stay. (In the Asia Pacific region, IDC anticipates the bring your own device (BYOD) market will continue its robust growth. There were an estimated 155 million smartphones and over 4 million tablets in use supporting BYOD initiatives across the region last year (2014), with year-on-year growth of 40.4 percent and 62.7 percent, respectively. And, that’s not even considering the burgeoning area of wearable devices, either.) As the mobile workforce accelerates like a rocket into the stratosphere, cascading torrents of smartphones, tablets, and wearables across organizations in its wake, the number of cloud- and SaaS-based applications used within organizations is also skyrocketing at a breakneck pace. According to a recent study sponsored by SkyHigh Networks, there are on average 759 cloud services in use by today’s organizations. The most puzzling piece isn’t the magnitude of in use cloud apps and services. Instead, its that, according to a Cloud Security Alliance study, most organization IT teams believe they have fewer than 50 cloud-based apps in use. That means that over 700 cloud apps and services on average are in use within enterprises – but no one (but the user) has control over those apps and services, and any corporate information shared with them! The problem is, you cannot defend what you don’t know about! Finally, the last piece of the “new norm” puzzle for organizations is the hybrid network, an eclectic mix of data center and cloud-based apps and data, with a stew of hosted private, public and cloud infrastructures. According to analyst Gartner, “while actual hybrid cloud computing deployments are rare, nearly three-fourths of large enterprises expect to have hybrid deployments by 2015.” Consider that a mobile workforce will drive infrastructure changes, needed to address a more diverse device ecosystem. Then consider that infrastructure addressing mobility requires greater investment in cloud-based apps and services to support that expanding device ecosystem. So, as you can see, the future of the network fabric for the foreseeable future will be hybrid. So, with a “new norm” of mobility, cloud, and hybrid networks, how can organizations address network, application, and data accessibility? With so many new devices that are mobile and are under limited corporate control, and applications and data scattered about the network and in various clouds and SaaS deployments, how can an enterprise be assured of fast, appropriate, authenticated and authorized access? With so many variables, there is one constant that remains: Identity. The user – and their identity – is, arguably, the “new perimeter” for the enterprise, today and onward. As the traditional network perimeter has been broken, fragmented, and in many instances shattered into many pieces, identity has become the new perimeter. As applications, data, and even networks move faster toward the cloud, and the user-controlled, BYOD-driven mobile ecosystem expands exponentially, corporate control has become more difficult, dispersed, and dependent on others – and many times, that’s the security uninformed and apathetic user. User identity, though, never changes. And, backed by authentication, authorization, and accounting (AAA), identity is now the first line of defense for secure corporate access. But, identity is just the tip of the spear for controlling the new parameters of access. The context of a user’s access request, and their environment at the time of access request, follow identity; inarguably, they have as much to do with securing appropriate access as identity. The ability to address the 5 w’s and 1 h (who, what, when, where, why, and how) assures, enhances, and differentiates secure access to networks, clouds, applications and data – wherever they may reside and however they are comprised. Insuring user identity is efficiently, securely shared between networks, clouds, applications, and data – wherever they live – is now a necessity. Yet, there are challenges: Identity silos, on-premise identity with cloud- and SaaS-based apps and data, and user password fatigue leading to weak user names and passwords – which are easily compromised. That’s where building an identity bridge comes in. Federation builds a trusted chain of user identity between two entities – networks, clouds, applications, etc. – through industry standards, such as SAML. The cumbersome duplication and insertion of identity directories becomes unnecessary. Identity and access is controlled by an enterprise, with authentication occurring between the enterprise, and cloud and SaaS providers. Instant user authentication and its termination is centralized and under enterprise control. Identity federation delivers access visibility and control together. Leveraging identity for access control, and building identity bridges are now imperative for organizations, as applications move outside the enterprise domain, the workforce and their devices are more mobile and leave the enterprises in droves, and the enterprise domain, too, has moved. It’s the “new norm”.The Mounting Case for Cloud Access Brokers
#infosec #cloud #iam Addressing the need for flexible control of access to off-premise applications Unifying identity and access management has been a stretch goal for IT for nearly a decade. At first it was merely the need to have a single, authoritative source of corporate identity such that risks like orphaned or unauthorized accounts could be addressed within the enterprise. But with a growing number of applications - business applications - being deployed "in the cloud", it's practically a foregone conclusion that organizations are going to need similar capabilities for those applications, as well. It's not easy, there are myriad reasons why unifying identity and access control is a stretch goal and not something easily addressed by simply deploying a solution. Federation of identity and access control requires integration. It may require modification of applications. It may require architectural changes. All of these are disruptive and, ultimately, costly. But the costs of not addressing the issue are likely higher. Security a Rising Concern for Cloud-Based Application Usage With access to these applications taking place from a variety of locations including smartphones (80 percent),tablets (71 percent) and non-company computers (80 percent) and with a large percentage of organizations (73 percent) needing to grant temporary access to cloud apps, respondents cited concerns around identity management, governance and complexity. ... Nearly three-quarters (72 percent) of the respondents said they have the need to provide external users, such as consultants, with temporary access to the company’s cloud applications, while just under half (48 percent) of respondents said they are still not able to sign in to cloud applications with a single set of credentials. [emphasis mine] There is a significant loss of control - in terms of governance - that's occurring, where the organization no longer has the means by which they can control who has access to applications, from what device or location, and when. That's the downside of cloud, of distributed systems that are not architected with security in mind. Make no mistake, it's not just IT making a power grab for power's sake. This is a real, significant issue for the business side of the house, because it is their applications - and ultimately data - that is at risk by failing to properly address issues of access. THE CASE FOR CLOUD ACCESS BROKERS The least disruptive - and most efficient - means of addressing this disconnect is to insert into the data center architecture an access broker tier, a layer of dynamic access and identity management services designed to provide federation and unification of credentials across cloud and data center resources based on the organization's authoritative source of identity. The advantages of such a tier are that they are less disruptive, it respects the authoritative source of identity and it is highly flexible. The same cloud access broker that provides authentication and authorization to internal resources can do so for cloud-based resources. The downside is integration with a growing variety of SaaS and custom cloud-deployed applications used by the enterprise. A standards-based way of integrating off-premise applications with a cloud access broker is needed, and we find such a standard in SAML 2.0, an increasingly popular means of integrating identity and access management services across the cloudosphere. In addition to providing access control through such integration, a cloud access broker also provides the means for IT to address the issue of password security noted in "Security a Rising Concern for Cloud-Based Application Usage": The survey indicated unsafe password management continues to be a challenge, with 43 percent of respondents admitting that employees manage passwords in spreadsheets or on sticky notes and 34 percent share passwords with their co-workers for applications like FedEx, Twitter, Staples and LinkedIn. Twenty percent of respondents said they experienced an employee still being able to log in after leaving the company. By enabling federation and single-sign on capabilities, organizations can mitigate this problem by ensuring users have fewer passwords to recall and that they do not share them with off-premise applications like FedEx. Because IT controls the authoritative source of identity, it also governs policies for those credentials, such as password length, history, interval of change, and composition. FEDERATION MEANS HEIGHTENED (AND ENFORCEABLE) SECURITY Federation of identity and access management through a cloud access broker can alleviate the loss of control - and thus expanding security threats. By maintaining the authoritative source of identity on-premise, organizations can enforce security policies regarding password strength and length while improving the overall experience for end-users by reducing the number of credentials they must manage to conduct daily business operations. Issues such as orphaned or rogue accounts having access to critical business applications and data can be more easily - and quickly - addressed, and by using a flexible cloud access broker capable of transitioning security protocols, device incompatibility becomes a non-issue. As more and more organizations recognize the ramifications of unfettered use of cloud services it is inevitable that cloud access brokers will become a critical component in the data center.Solving Substantiation with SAML
Organizations are deploying distributed, hybrid architectures that can span multiple security domains. At any moment, a user could be accessing the corporate data center, the organization’s cloud infrastructure, or even a third party, #SaaS web application. #SAML can provide the identity information necessary to implement an enterprise-wide single sign-on solution. Proving or asserting one’s identity in the physical world is often as simple as showing a driver’s license or state ID card. As long as the photo matches the face, that’s typically all that is needed to verify identity. This substantiation of identity is a physical form of authentication, and depending on the situation, the individual is then authorized either to receive something or to do something, for instance, enter a bar, complete a purchase, etc. In the digital world, identity verification is not as easy as showing the computer monitor a driver’s license. To gain entry, you must provide information like a name, password, randomly generated token number—something you have, something you know, or something you are—to prove you are who you say you are. Gaining access to corporate assets is no different. Many organizations have multiple different resource portals, however, each requiring digital proof of identity. Their users may also need to access partner portals, cloud based Software as a Service (SaaS) applications, or distributed, hybrid infrastructures that span multiple data centers, each requiring a unique user name and password. In addition, the average employee must maintain about 15 different passwords for both her private and corporate identities, with many of those passwords also being used for social media and other risky entities. Statistics show that 35 to 50 percent of help desk calls are related to password problems, with each call costing a company between $25 and $50 per request. Security Assertion Markup Language (SAML) is an XML-based standard that allows secure web domains to exchange user authentication and authorization data. It directly addresses the problem of how to provide the users of web browsers with single sign-on (SSO) convenience. With SAML, an online service provider can contact a separate online identity provider to authenticate users who are attempting to access secure content. For example, a user might need to log in to Salesforce.com, but Salesforce (the service provider) has no mechanism to validate the user. Salesforce would then send a request to an identity provider, such as F5 BIG-IP® Access Policy Manager (APM), to validate the requesting user’s identity. BIG-IP APM version 11.3 supports SAML federation, acting as either a service provider or an identity provider, enhancing the employee’s online experience and potentially reducing password-related tickets at the help desk. BIG-IP APM version 11.3 can act as either a SAML service provider or a SAML identity provider, enabling both federation and SSO within an enterprise. BIG-IP APM as a Service Provider When a user initiates a request from a SAML IdP and the resources, such as an internal SharePoint site, are protected by BIG-IP APM, BIG-IP APM consumes that SAML assertion (claim) and validates its trustworthiness. This ultimately allows the user access to the resource. If the user goes directly to BIG-IP APM (as an SP) to access a resource (like SharePoint), then the user will be directed to the IdP to authenticate and get an assertion. Once a user is authenticated with a SAML IdP and accesses a resource behind BIG-IP APM, he or she will not need to authenticate again. BIG-IP APM as an Identity Provider Provided there is an SP that accepts assertions, a user can authenticate with BIG-IP APM to create an assertion. BIG-IP APM authenticates the user and displays resources. When the user clicks on an application, BIG-IP APM generates an assertion. That assertion can be passed on to the SP, which allows access to the resource without further authentication. When the user visits the SP first, the process is SP initiated; when the user goes directly to the IdP (in this case, BIG-IP APM) first to authenticate, the process is IdP initiated. BIG-IP APM in a SAML Federation SAML can be used to federate autonomous BIG-IP APM systems. This allows a user to connect to one BIG-IP device, authenticate, and transparently move to other participating BIG-IPs devices. Session replication is not part of SAML, but administrators can populate session information on participating systems. This means that BIG-IP device federation does not enable the use of a single session within the federation; it only enables information exchange among multiple members of the federation. Each participating BIG-IP device maintains its own independent session with the client, and each has its own access policy that executes separately and independently. Participating federation members can exchange information with any other federation members outside of sessions where needed. A common configuration is to have a dedicated BIG-IP device as a primary member to which users are authenticated and that provides information to other members. This allows a number of other BIG-IP devices to work in conjunction with that primary member. The primary member is dedicated as an IdP, while the other participating members operate as SPs Benefits The benefits of deploying BIG-IP APM as a SAML solution certainly include better password management, fewer help desk calls, and an improved user experience, but BIG-IP APM can also add additional context to requests. For instance, it can include endpoint inspection results as attributes to inform the application of the client’s security posture. In addition, IT administrators do not need to retrofit applications (e.g., .NET apps do not need a Kerberos claims plug-in). Another advantage is extensive session variable support, which allows organizations to customize each user session. BIG-IP APM can bring SAML to resources and applications with minimal back-end changes—or none. These benefits all complement the values of BIG-IP APM to the overall traffic management of an organization’s IT infrastructure. IT infrastructure has changed dramatically over the past few years, with many applications moving to cloud-based services. Corporate employees have also morphed into a mobile workforce that requires secure access to that infrastructure any time, from anywhere, and with any device. Bridging the identity gap between physically and logically separated services allows organizations to stay agile in this ever-changing environment and gives users the secure access they need around the clock. BIG-IP APM version 11.3, in addition to delivering high availability and protecting organizations’ critical assets, provides a SAML 2.0 solution that offers the identity bridge needed to manage access across systems. ps Related: SAML Federation with BIG-IP Access Policy Manager: Inside Look – Video Solving Substantiation with SAML – White Paper BIG-IP Access Policy Manager Overview (pdf) F5 Enhances Application Delivery Security with the World’s Fastest Firewall F5's YouTube Channel In 5 Minutes or Less Series (22 videos – over 2 hours of In 5 Fun) Technorati Tags: saml,big-ip,f5,access,security,apm,v11.3,silva,authentication,cloud computing,federation Connect with Peter: Connect with F5:
