Q&A: Your Questions about Expanding SSO to Comprehensive Access Management Answered
What are the benefits of expanding your federated SSO deployment into a comprehensive access management framework?
That was the central topic on a recent Q&A roundtable webinar, hosted in April by three Ping Identity product managers. They showed how deploying PingFederate and PingAccess together enables you to extend single sign-on (SSO) to more applications, add more granular authorization and centralize session management capabilities.
Implementing PingAccess alongside PingFederate addresses these three key challenges for our customers:
1. Extend SSO to all applications.
Challenge: PingFederate provides a range of convenient approaches to enable single sign-on, but some apps might not natively support federation standards like SAML and OAuth 2.0 and OpenID Connect, while others might be protected by agent-based legacy web access management (WAM) agents.
Solution: When PingFederate and PingAccess are deployed together, you can easily extend single sign-on to all applications through HTTP header injection, JWT tokens and even token mediation to applications protected by legacy web access management agents. Our partnership with Microsoft also allows you the additional benefit of leveraging your identities in Azure AD to maintain SSO for all of your on-premises applications.
2. Add a granular authorization layer to your IAM architecture.
Challenge: Some resources are too sensitive for yes/no access decisions, and you need a way to allow access to only certain administrative functions and resources within applications and APIs.
Solution: When you deploy PingFederate and PingAccess together, you can provide access control at a deeper level for apps and APIs. Granular control at the URL level allows for varying levels of administrative access to different applications, and you can restrict HTTP methods available for different users with APIs.
3. Centralize and upgrade session management.
Challenge: Applications come in all shapes and sizes, and some resources are more sensitive than others. Decentralized session parameters and global session cookies aren’t ideal for delivering the appropriate level of access security to match the risk.
Solution: When you deploy PingAccess with PingFederate, session management can be abstracted from individual applications into centralized administration to ensure that appropriate session parameters (policies for items like timeout windows and changes in user context) for more sensitive resources are put in place. And rather than a global session cookie for all resources, PingAccess can require applications to accept only encrypted and scope-specific session tokens to prevent “man-in-the-middle” attacks.
The Roundtable: Answers from Ping Experts
A recent webinar panel of PingAccess Product Manager Mark Bostley, PingFederate Product Manager Scott Tomilson and PingFederate Product Manager Eric Fazendin, along with host Product Marketing Manager Andrew Goodman, answered a variety of questions from the audience. Here are some of the most intriguing queries.
WAM Migration
Q: When migrating to PingAccess, is a forklift upgrade from products like SiteMinder and Oracle Access Manager required, or is a phased approach possible?
Mark Bostley: We enable a phased approach where applications are moved as they're ready while maintaining a consistent user experience from single sign-on, to the type of authentication, to all of the interactions that you would have with the user's browser or the user's client.
Q: Can you tell us about token mediation and how various WAM products are supported?
Mark Bostley: PingAccess makes an STS call to PingFederate and presents enough information that PingFederate can issue a token for that user on whatever the platform or whatever the proprietary token is. Then PingAccess takes that token on the back end and embeds that into the request so it is as if it came from the browser.
Extending SSO
Q: How is SSO and application integration made easier with PingAccess?
Mark Bostley: Take integration using Azure AD as the identity provider as an example. We'll take the user information out of the OAuth or OpenID Connect context and add attribute-value pairs to the header that gets passed to the backend application. This is a pretty lightweight application, developer-friendly way of passing information into an application so they can do things like customizing user experience or even doing application-level entitlements.
Q: How does PingFederate help to modernize an enterprise’s application portfolio to include SaaS apps and APIs?
Eric Fazendin: Through PingFederate’s context-based authentication policies, tokens are issued to SaaS applications in the form of SAML assertions or standards-based SSO. For APIs, PingFederate issues all access tokens to OAuth-enable or really identity-enable API calls that are made from an OAuth client to some backend API resource.
Q: How do PingFederate and PingAccess communicate with each other?
Scott Tomilson: In a couple ways, and using open standards as much as possible. It could be an API security use case where PingAccess is acting as an OAuth resource server protecting APIs, and PingFederate is the OAuth authorization server. Another use case would be PingAccess and PingFederate support for web access management. Administrative-wise, calls between PingAccess and PingFederate through admin APIs over HTTPS make all that magic happen.
Enhancing Security and Session Management
Q: Regarding SDK capabilities and Groovy scripts, what systems are customers typically leveraging to bring in outside data?
Mark Bostley: We're working on implementing the ability to include an HTTP client in custom objects created inside of PingAccess, and we plan to introduce that functionality in the next couple of months. Anything that is a rule or even an identity mapping, load balancing scenarios, a custom-developed object using our SDK, could potentially use this HTTP client to make API calls as part of its processing.
Q: Is it possible to coordinate session timing between PingFederate and PingAccess?
Scott Tomilson: Absolutely. PingFederate and PingAccess operate independently in many cases, but we use OpenID Connect to bootstrap the PingAccess session. You can embed in that session, you can embed an access token in there, so PingAccess periodically updates refresh attributes inside the session token. It can also do revocation checks and timeout sliding.
Deployment Architecture, Administration & Integration
Q: Is there an automated way of migrating a dev environment of PingFederate to production?
Scott Tomilson: You can entirely script the entire operation; it doesn't have to be manual. When migrating an SP connection in PingFederate from a staging dev environment into production, there are admin APIs where you can easily query the connection, we get a JSON representation of that, and then post it to a production environment.
Q: Does PingAccess support automation features native to AWS?
Mark Bostley: For AWS, we've built cloud formation templates, lambda functions, cloud watch rules and a bunch of other objects for customers to use. For people who are familiar with AWS, they can take those scripts and they can modify them to suit their specific needs.
Q: Is it possible to offer self-service capabilities to application owners with PingAccess?
Mark Bostley: Anything you would expect an application owner to configure can be done through the API and enabled through our own UI or an external UI targeted specifically at app owners.
Q: Is there an ability to back out or restore configurations during the upgrade process?
Scott Tomilson: The upgrades are really side by side, so you take a parallel install of the software, and you run the upgrade utility to migrate configuration from one version to another. If you see any issues after you’ve done the upgrade, it's easy to shut down the upgraded version and restart the old version.
