Doesn't take long for people to make Ping feel like home.
Doesn't take long for people to make Ping feel like home.
By David Gorton
Over the past couple weeks in this blog series, we have discussed the inadequacy of traditional identity and access management (IAM) systems in comparison to our Next Gen Identity™ platform. We have also reviewed how simple the migration process is from CA SiteMinder® (now called CA Single Sign-On) to Next Gen Identity™. This week, we'll explore the technical strategies for authentication when planning a migration.
While the process of migrating from CA SiteMinder to the Ping Identity Next Gen Identity platform is not complex, there is one strategic technical decision that must be made during the planning cycle that will directly impact end-user experience during migration. To start, providing a single sign-on (SSO) experience is critical to shield the end-user from the complexities of two identity security systems. Most migrations would require the user to authenticate separately for each security system. In contrast, our Next Gen Identity solution provides a single sign-on experience across both systems during the migration. In order for the migration experience to be ideal, the authentication system of record must be determined very early in the migration process. Therefore, determining this authentication system of record is an important and strategic technical decision to make during the planning cycle.
It is critical that the authentication system is specified during the planning process. There are two choices for the authentication system: PingFederate® or CA SiteMinder. The authentication system is responsible for authenticating the user against the directory or identity store. Rather than having both CA SiteMinder and PingFederate authenticate users against a single identity store, one system should be selected to authenticate the user. Ultimately, PingFederate will be integrated with CA SiteMinder to provide the single sign-on experience.
There are two strategy options for migrating the system of authentication. The first is to select PingFederate as the system of authentication at the beginning of the migration process. The drawback to this option is that the end-user must authenticate with PingFederate before they can access a CA SiteMinder protected application. When migrating, this can be difficult to configure within CA SiteMinder. However, this early migration provides more flexibility for customizing authentication policies and leveraging those policies when accessing cloud-based applications.
The second option for migrating the system of authentication is placing CA SiteMinder (rather than PingFederate) as the system of authentication. This option delays the migration of authentication policies until the very end of the migration process. It also requires that PingFederate be tightly integrated with CA SiteMinder to honor and validate CA's identity tokens. The drawback to this option is the loss of flexibility for using authentication policies that are the same between on-premise applications and cloud-based applications. Ultimately, the authentication policies located in CA SiteMinder will be migrated to PingFederate when implementing the Next Gen Identity solution.
Regardless of which authentication strategy you choose, it is important to keep the end-user experience in mind. The migration from one identity security system to another should be transparent to the end-user.
Our Next Gen Identity solution is the only identity security product that enables seamless migration between identity security solutions. End-users won't know the difference, but IT will be able to securely leverage infrastructure as a service (IaaS), apply the same security policies to web and API resources and easily share applications with customers and partners.
To learn more about the technical details of migration from CA SiteMinder, download our CA SiteMinder migration guide.
Next week, we will conclude this series by discussing the capabilities of the Next Gen Identity solution and platform. In the meantime, check out this comparison checklist of capabilities between Next Gen Identity and traditional systems such as CA SiteMinder.
By David Gorton
Today, Ping Identity has released updates to the foundation of our Federated Access Management solution with PingFederate 7.3 and PingAccess 3.1. This release centers on the Federation Hub in PingFederate and advanced attribute and session management capabilities with PingAccess--driving revenue and reducing risk for the enterprise.
The Federation Hub feature of PingFederate stops the worry about which federation protocol you need to support in order to connect with your customers, partners and applications. The benefit is that you can easily connect your applications and your identity providers together to share information, build business partnerships and drive revenue without federation protocol limits. You can also stop negotiating and enforcing federation support for specific applications. Instead, may now use the Federation Hub to coordinate the protocols from the identity provider and service provider. The Federation Hub coordinates the protocols by accepting a SAML assertion or WS-Federation token and then translating that token into the appropriate federation token format for the application.
The Federation Hub also centralizes and simplifies administration by multiplexing a single application to many IDPs. Administrators can easily add and update federation relationships without affecting an application. Additionally, multiplexing supports many federation relationships to an application constrained to a single federation connection, like Microsoft® SharePoint.
IdP discovery becomes more important with the Federation Hub when multiplexing is involved. Adaptive Federation features enable PingFederate to select an IdP based on contextual information available from an authentication request, such as source IP address, requested level of assurance and user agent details. This simplifies the selection of the correct identity provider without onerous question and answer processes.
PingFederate has also matured the OAuth 2 Authorization Server to strengthen identity security for APIs, mobile applications and server-to-server communication. Now you can customize authentication and identity requirements for each API client or application while integrating with existing identity stores. When combined with PingAccess, these changes provide a complete, customizable identity security framework for all clients and their corresponding APIs.
In addition to its API security capabilities, PingAccess can now capture and react to changes in identity stores. As administrators update user groups or other identity attributes, a user's web session is updated with the latest information. With this latest information, security can be enforced against an up-to-date user profile.
The real value to continuous updates for attributes is what happens when users are deleted or disabled. When the 'delete' or 'disable' event is detected, all single sign-on (SSO) and web access management (WAM) sessions are immediately terminated. Additionally, this functionality can be plugged into the OAuth 2 Authorization Server to invalidate all access tokens for the users. With the single delete or disable event, a user will lose access to all applications regardless of the client involved.
PingAccess 3.1 also brings built-in load balancing features that reduce the network complexity and total infrastructure cost of moving from an agent-based architecture to a gateway-based architecture. PingAccess also monitors and manages fail-over across multiple servers for a single application.
PingFederate 7.3 and PingAccess 3.1 are the most secure and federation-capable releases Ping Identity has shipped to date. To learn more about these features, please tune into the upcoming webinar with Ping Identity product managers on March 31st.
Click here to download the latest versions.
By John Fitzgerald
Growing up in the 1980's, one of my favorite movies was War Games. In the movie, Matthew Broderick plays a smart, lazy and rebellious student who loves computers and is a "hacker". In his attempt to impress a girl, he breaks into their school's computer to change their grades. A few plot twists later and he almost starts World War III.
Watching the movie today, it is funny to see how much the technology has changed. We no longer use an acoustic coupler to connect to another computer, you can be "online" and still use your landline (if you still have one) and graphics quality in video games rival real life. What is not funny is that over 30 years later, the same paradigm of username and password is used to control access to applications. In the movie, David opens the drawer, finds the password and "Joshua" is bringing us to DEFCON 1. Same thing happens today. End users reuse passwords and write them on sticky notes.
To better protect access to applications, we need more than just a username and a password. That's where multifactor authentication (MFA) solutions, like PingID, can help. With MFA, a user is prompted for a second factor of authentication when they log in. In the case of PingID, it takes the form of an app running on a phone. The user has to have the phone to authenticate. Finding the password on the sticky note is not enough. With MFA, an organization can easily protect against unauthorized access to applications.
If the WOPR had some form of MFA, David would never have been able to play "Global Thermonuclear War". PingID can call a phone like the Motorola DynaTAC to deliver a one-time passcode via voice (but I might be taking this story a little too far).
Check this out to see why the password paradigm is really a thing of the past.