HVL/Nulli Secundus 2001 Designing a Single Sign On Strategy Guy Huntington, President HVL Derek...

HVL/Nulli Secundus 2001

Designing a Single Sign On Strategy

Guy Huntington, President HVLDerek 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?



• 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



• 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?



• 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?



• 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?



• 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:• [email protected]• www.hvl.net• 604-921-6797

Derek Small, Nulli Secundus• [email protected]• www.nulli.com• 403-270-0657


Securing E-Business Presentations…

www.hvl.net/ebusiness.htm

Date post:	15-Dec-2015
Category:	Documents
Upload:	rachael-wylie
View:	219 times
Download:	3 times

HVL/Nulli Secundus 2001 Designing a Single Sign On Strategy Guy Huntington, President HVL Derek...

Documents