420 likes | 663 Views
Designing a Single Sign On Strategy. Guy Huntington, President HVL Derek Small, President Nulli Secundus. The Issue. Single sign on (SSO) today is a common buzzword and goal for many enterprises
E N D
Designing a Single Sign On Strategy Guy Huntington, President HVL Derek Small, President Nulli Secundus
The Issue • Single sign on (SSO) today is a common buzzword and goal for many enterprises • It’s extremely complex once you peel away the outer layer of strategic desire and look at the system and security implications • Do you know what to look for when considering your SSO strategy?
Have You Thought About… • Authentication schemes? • Identity management? • Post authentication actions? • Authorization? • Post authorization actions? • System integration? • Directory strategies? • Auditing? • Overall risk?
The Good News Is SSO… • Provides end user ease of use • Can reduce or eliminate security lapses between multiple authentication and authorization systems
The Bad News Is SSO… • Creates a potential single source of primary authentication which, if vulnerable to attack at any point in the process, can provide a malicious or unwanted person with an entrée to your systems
What’s Driving SSO? • End users can’t handle remembering all the different passwords to access the many systems they deal with daily • They don’t want to carry in their wallets many separate forms of authentication devices such as loyalty cards, credit cards, smart cards, employee and other forms of ID
It’s a Process, Not a Product • SSO isn’t something you buy, nor is it just a single password a user has to remember • SSO is a process made up of many sub-components and system interfaces with some form of business driven security logic driving those components • It’s only as good as the weakest link in the chain
Islands of Trust • Most system within an enterprise weren’t built with common authentication systems in mind • Therefore, most enterprises have many independent authentication and authorization islands • There are generally few or no standards for these authentication systems
Different Trust • Each of these authentication islands uses different approaches to trust • Some have an all or none approach • They give you complete or no access to the system/network
DifferentApproach • Others tend to use one authentication method and several layers of authorization • As you drill towards more and more sensitive information it requires higher levels of authorization but still uses the initial authentication
Multiple Layers of Trust • A few system use both multiple levels of authentication and authorization • As you drill towards more sensitive information the levels of both authentication and authorization increase
Key Question • The core question at the heart of SSO is whether to build bridges between the authentication and authorization islands, reduce the number of islands or keep the islands separate?
Building Bridges • You have to address: • Keeping communications secure • Creating common authentication processes (which may not be easy between disparate authentication systems) • Synchronizing the systems so they never get out of step • Accepting levels of trust between systems • Some form of directory strategy
ReduceIslands • If you reduce the number of authentication islands, you have to re-engineer systems • Most likely requires a modern directory strategy • Takes time, money and effort • Potentially offers new economies of scale • Standardize authentication, authorization and auditing security
Separate Islands • Enforce separate security levels for each system • This works where the risk is high and end users accept the additional authentication process • It fails in modern e-business solutions where end users want single sign on and simplicity for authentication
The SSO Onion • We prefer to view the process of achieving SSO like peeling away the layers of an onion • Each internal layer is a higher measure of trust all applications will accept with accompanying authentication, authorization and auditing components • This should be a goal in working with vendors and reengineering your legacy systems
Reality • The reality is you’re not going to reengineer all your systems over a short period of time just for SSO • It’s too expensive, time and effort consuming • So you need to develop some interim solutions that get you on the road towards SSO, provide ease of use for your users and enhance existing security
Where to Start? • Prioritize your authentication needs • Consider a directory strategy • Consider infrastructure tools • Develop building blocks • Have a global security strategy
Prioritize Your Needs • Before you leap to vendors and product solutions, determine the SSO priorities • What’s the cost/ease of use/risk analysis for achieving SSO for your applications?
Prioritize Your Needs • Take a look at the current costs for maintaining independent authentication • A place to look is help desk support required for lost passwords • Another place to look is the cost in entering and maintaining username and passwords between systems
Prioritize Your Needs • What’s the biggest gripe from your user community re authentication? • What levels of inconvenience will they accept? • Do you have current risk analysis for your existing systems? • What’s the risk analysis if you went to SSO?
Prioritize Your Needs • Does SSO give you a competitive advantage? • Would it be perceived by your customers as an advantage over your competition? • Could you use it to leverage workflow with your business partners and customers coming in via portals or the webs?
Directory Strategy • SSO is very hard to achieve without a directory strategy • Directories are good for fast lookups like authentication and authorization
Directory Strategy • Directories operate to global IETF LDAP standards • They can help integrate authentication, authorization and auditing for the network and back office systems such as ERP, HRIS and data warehouses • You need some sort of coordinating hub for SSO to work
Directory Strategy • Even such basic concepts of username and password are hard to coordinate between systems without a directory • Most systems use different syntax, length, management and storage policies for username and password
Directory Strategy • A directory is also key in coordinating form, certificate and biometric authentication schemes between your many systems • It can both store and replicate data to and from the authentication systems
Identity Management • A big challenge is coordinating the identity knowledge between systems • How do you synch up the management of identities of potentially millions of customers, thousands of business partners’ employees and thousands of your own employees?
Identity Management • You need to not only synchronize systems but push secure identity management down to the appropriate level • This may include end user self service for maintenance of their basic information and password
Coordinating Authentication Schemes • How are you going to handle different authentication methods for each application? • Are you starting to deploy form, certificate and biometric authentication?
Coordinating Authentication Schemes • Are you using or considering SSL/TLS and hashing algorithms to secure authentication? • How are you going to maintain state between applications given the internet is stateless? • How are you going to mesh this all together and manage it?
Coordinating Authentication Schemes • How are you going to recognize different levels of trust between applications? • Are you going to accept common levels of trust? • How are you going to handle users from different domains? • How are you going to handle different authentication timing actions?
Post Authentication • When a central system authenticates, what are the post authentication actions between it and each of your other islands? • Are you passing HTTP headers, servlets, applets, or Javascript between them? • How are you going to handle integration to your portals, data warehouses, NOS’s, directories, ERP, HRIS and other systems?
Authorization • How are you going to handle authorization? • Are you going to centralize some of it, while also meshing it with the business and authorization logic in your ERP, HRIS or other systems? • What authentication and authorization information do you need passed from the SSO central hub that will allow the level of trust to be approved?
Post Authorization • What happens when an authorization succeeds? • Do you need to pass attributes in HTTP headers or launch applets, servlets, etc? • What if authorization fails? What happens to the user and in your auditing between systems?
Auditing Systems • How do you presently audit events? • Is it granular enough? • How are you going to synch up different auditing systems and events from the firewalls, NOS’s, ERP, HRIS, data warehouses and other systems?
Scaling Systems • How are you going to scale SSO within your enterprise? Between you and your business partners? With your customers? • How do you scale and coordinate the identity management, authentication, authorization and auditing systems on a local, regional, continental and global scale?
Consider New Tools • Having directories is not enough • You must synch up the disparate identity, authentication, authorization and auditing systems with something that is secure, scalable and manageable • This isn’t easy to do on your own • E-Business infrastructure tools from companies such as Oblix, Netegrity, Entrust, IBM/Tivoli are essential
Oblix NetPoint • In our practice we use Oblix NetPoint • Manages the identity piece with delegatable administration down to the end user if desired • Coordinates different authentication, authorization and auditing required at different levels of resource and identity granularity
Oblix NetPoint • Delegate policy administration • Scales quickly and securely using different forms of authentication, encryption, web and directory servers
SSO is Not a Panacea • SSO is a process that needs to be very carefully thought out before embarking down the vendor and product solution road • The process needs continual review, testing and monitoring to ensure integrity • It requires standards and well thought out work-arounds between disparate systems
I’d Like to Learn More … Guy Huntington, HVL: • guy@hvl.net • www.hvl.net • 604-921-6797 Derek Small, Nulli Secundus • derek@nulli.com • www.nulli.com • 403-270-0657
Securing E-Business Presentations… www.hvl.net/ebusiness.htm