??????????Enterprise Single Sign-on
Single sign-on made simple
A consequence of today’s increasingly decentralized IT environments is
the proliferation of passwords and
the burden they present to users. Organizations want to reduce this complexity while improving security and operational efficiency.
Single sign-on (SSO) can be the answer to these tough challenges. Unfortunately, most single sign-on solutions are limited in scope, require costly and hard-to- manage additional infrastructure, or demand ongoing maintenance. In
many cases, these solutions actually increase the complexity they are supposed to simplify.
Enterprise Single Sign-on, a part of the Dell One Identity products from Dell Software, addresses these challenges. As the industry’s leading enterprise SSO solution, it makes single sign-on simple and secure. Enterprise Single Sign-on requires no hard-to-manage infrastructure, and streamlines both user management and enterprise-wide administration of single sign-on.
“Configuring SSO for our applications was very simple—a prototype was set up in just a
few days. The actual implementation was done over the space of a few months, providing extremely rapid ROI.”
IT security manager for a major telecommunications organization
Benefits:
• Bases single sign-on on Active
Directory or any other LDAP identity
store
• Enforces security and access policy
enterprise-wide
• Implements a single point of strong
authentication for all resources
• Enhances IT and user efficiency
• Helps you achieve regulatory
compliance
??????????1. Authentication in the domain
2. Enterprise Single Sign-on retrieves application data
Enterprise Single Sign-on fills in the login dialog
5.
ERP
Mainframe
Web
???????????????Windows Server Active Directory
Enterprise Single Sign-on
3. 4.
An application is launched by a user – Enterprise Single Sign-on detects the login dialog
Enterprise Single Sign-on retrieves the secondary ID/password from its encrypted memory
???Enterprise Single Sign-on extends the Windows logon to all password-protected applications.
?Features
Active Directory-based single sign- on—Base single sign-on and access control for the entire enterprise on
the existing identities, groups and policies built into your existing Active Directory deployment, without requiring additional authentication methods or a metadirectory.
Security & access policy enforcement—
Use established access policies and Active Directory rules to apply similar controls to client-based SSO for
the entire enterprise-wide range of applications and systems to which a user may need access.
A single point of strong authentication—
Provide a single point of user authentication to any system and application. This includes standard username/password logins as
well as the entire range of strong authentication options, such as smart cards, biometrics and token-based two- factor authentication.
Improved IT & user efficiency—Relieve IT staff of the burden of managing user access and resetting passwords across a wide range of applications. Enhance user productivity by freeing users from having to remember passwords for multiple systems and applications.
Compliance support—Achieve compliance with common requirements for access control, strong authentication and secure delegation of access rights by implementing a consistent, strong, Active Directory-based infrastructure for access policy enforcement.
Auditing and reporting—Generate audit reports from sign-on or LDAP data, including statistics if desired, from an intuitive, easy-to-use interface.
Drag-and-drop configuration—Adapt applications to your unique environment with ease, without modification or custom connectors.
Optional fast user switching—Enable users to share a physical workstation using individual authentication and real- time context switching.
Optional password reset—Enable users to manage their own network password resets by answering secret questions from a web interface or a Windows login interface.
About Dell Software
Dell Software helps customers unlock greater potential through the power
of technology—delivering scalable, affordable and simple-to-use solutions that simplify IT and mitigate risk. This software, when combined with Dell hardware and services, drives unmatched efficiency and productivity to accelerate business results. www.dellsoftware.com.
?System requirements
For complete system requirements, please visit software.dell.com/products/ esso
????Dell Software
5 Polaris Way, Aliso Viejo, CA 92656 | www.dell.com
If you are located outside North America, you can find local office information on our Web site.
© 2013 Dell, Inc. ALL RIGHTS RESERVED. Dell, Dell Software, the Dell Software logo and products—as identified in this document—are registered trademarks of Dell, Inc. in the U.S.A. and/or other countries. All other trademarks and registered trademarks are property of their respective owners. Datasheet-ESSO-US-GM-23536
?

Data and Applications Security Developments and Directions
Dr. Bhavani Thuraisingham
The University of Texas at Dallas

Single-Sign On and Federated Identity Management

November 30, 2009
Outline
Single Sign-On
Reference: en.wikipedia.org/wiki/Single_sign-on
Federated Identity Management
Reference: en.wikipedia.org/wiki/Federated_identity

Open ID, Information Card

en.wikipedia.org/wiki/OpenID

en.wikipedia.org/wiki/Information_Card
Single Sign-On
Single sign-on (SSO) is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again.
Single sign-off is the reverse process whereby a single action of signing out terminates access to multiple software systems.
As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication
Single Sign-On
Kerberos based
Initial sign-on prompts the user for credentials, and gets a Kerberos ticket-granting ticket (TGT.)
Additional software applications requiring authentication, such as email clients, wikis, revision control systems, etc, use the ticket-granting ticket to acquire service tickets, proving the user’s identity to the mailserver / wiki server / etc. without prompting the user to re-enter credentials.
Windows environment – Windows login fetches TGT. Active directory-aware apps fetch service tickets, so user is not prompted to re-authenticate.
UNIX/Linux environment – Login via Kerberos PAM modules fetches TGT. Kerberized client applications such as Evolution, Firefox, and SVN use service tickets, so user is not prompted to re-authenticate.
Single Sign-On
Smart card based: Initial sign on prompts the user for smart card. Additional software applications also use the smart card, without prompting the user to re-enter credentials. Smart card-based single sign-on can either use certificates or passwords stored on the smart card
Client Certificate Based: Shared Authentication Schemes which are not Single Sign-On
Single sign on requires that users literally sign in once to establish their credentials. Systems which require the user to log in multiple times to the same identity are inherently not single sign on. For example, an environment where users are prompted to log in to their desktop, then log in to their email using the same credentials, is not single sign on. Shared authentication schemes like OpenID, which require additional sign-on for each web site, are also not single sign on.

Single Sign-On
Enterprise Single Sign-On
Enterprise single sign-on (E-SSO) systems are designed to minimize the number of times that a user must type their ID and password to sign into multiple applications.
The E-SSO solution automatically logs users in, and acts as a password filler where automatic login is not possible. Each client is typically given a token that handles the authentication, on other E-SSO solutions each client has E-SSO software stored on their computer to handle the authentication. On the server side is usually an E-SSO authentication server that is implemented into the enterprise network.

Federated Identity Management
Federated identity, or the òfederation’ of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains.
The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. Identity federation comes in many flavors, including òuser-controlled’ or òuser-centric’ scenarios, as well as enterprise controlled or B2B scenarios.
Federated Identity Management
Federation is enabled through the use of open industry standards and/or openly published specifications, such that multiple parties can achieve interoperability for common use cases.
Typical use-cases involve things such as cross-domain, web-based single sign-on, cross-domain user account provisioning, cross-domain entitlement management and cross-domain user attribute exchange.
Federated Identity Management
Use of identity federation standards can reduce cost by eliminating the need to scale one-off or proprietary solutions.
It can increase security and lower risk by enabling an organization to identify and authenticate a user once, and then use that identity information across multiple systems, including external partner websites.
It can improve privacy compliance by allowing the user to control what information is shared, or by limiting the amount of information shared.
It can drastically improve the end-user experience by eliminating the need for new account registration through automatic òfederated provisioning’ or the need to redundantly login through cross-domain single sign-on.
Federated Identity Management
Leading enterprises around the world have deployed identity federation to get closer with partners, improve customer service, accelerate execution of business partnerships and alliances, cut cost and complexity of integrating outsourced services, and free themselves from vendor lock-in.
End-users and consumer focused web sites are now beginning to engage in identity federation through the adoption of OpenID, which is an open source specification for enabling federation use-cases.
Federated Identity Management
The notion of identity federation is extremely broad, and also evolving. It could involve user-to-user, user-to-application as well as application-to-application use-case scenarios at both the browser tier as well as the web services or SOA (service-oriented architecture) tier.
It can involve high-trust, high-security scenarios as well as low-trust, low security scenarios. The levels of identity assurance that may be required for a given scenario are also being standardized through a common and open Identity Assurance Framework.
It can involve user-centric use-cases, as well as enterprise-centric use-cases. The term òidentity federation’ is by design, a generic term, and is not bound to any one specific protocol, technology, implementation or company.
Federated Identity Management
One thing that is consistent, however, is the fact that òfederation’ does describe methods of identity portability which are achieved in an open, often standards-based manner -meaning anyone adhering to the open specification or standard can achieve the full spectrum of use-cases and interoperability.
Identity federation can be accomplished any number of ways, some of which involve the use of formal Internet standards, such as the OASIS SAML specification, and some of which may involve open source technologies and/or other openly published specifications, (e.g. Information Cards, OpenID, the Higgins trust framework or Novell’ s Bandit project).

Active Directory and Oxford Single Sign-On
Bridget Lewis -ICTST
Adrian Parks -OUCS
Aim

How to link Active Directory to the Oxford Kerberos Single sign-on (SSO) infrastructure
What is Kerberos?
Authentication protocol
Not authorisation
Client and server mutually authenticate
Authentication vs Authorisation
Why Kerberos?

Single sign-on
Centralised authentication
Strong encryption
No passwords over the wire
Kerberos in Oxford

Herald
WebLearn
Apache/IIS webservers (via Webauth)

eDirectory
Active Directory
Open Directory
So how does it work ?

Simple, really
Like this

Essential Terminology
Principal î user or service with credentials
Ticket î issued for access to a service
Key Distribution Centre (KDC) î issues tickets for principals in a realm
Realm î set of principals in a Kerberos database, e.g. OX.AC.UK, OUCS.OX.AC.UK
TGT (ticket-granting ticket) î confirms identity; used to obtain further tickets (Single Sign-on)
Kerberos and Active Directory
Kerberos 5 implemented in AD (with added )
Every domain is a Kerberos Realm
Every domain controller is a KDC
Many services can use Kerberos
CIFS, LDAP, HTTP
Kerberos is preferred over NTLM
Trusts between Kerberos Realms

Integrating Active Directory with Oxford Kerberos Realm
Configure Active Directory Kerberos realm to trust Oxford Kerberos realm for authentication
Integrating Active Directory with Oxford Kerberos Realm
Authorization: AD uses SID, not username to determine what a user can do
Usernames must exist in AD (Identity Management)
Oxford usernames must be mapped to Active Directory users
So what does this mean in practice?
The Good …

Use Oxford account to authenticate to AD
No need to issue passwords to new students each year
Devolve password problems to OUCS
Case Study
St Hugh’ s College
~ 20 Public Access PCs
~ 600 Students, intake of ~120 per year
Passwords were issued manually each year

Integrated with Oxford KDCs
Account creation simplified via VB script
Students use Herald password
Administrative overhead reduced for ITSS

Case Study
Language Centre
User base is whole university!
Potentially 40000 users
Historically, all used one shared account

Webauth plus Oxford SSO solution
Users register for AD account via Webauth protected site
AD account generated on the fly
Log in to AD via the Oxford SSO solution
Herald password

But there are some caveats
The Bad …

Access from PCs not in domain
Including via web, e.g. Outlook WebAccess
Some students don’ t know their Oxford password (approx 13%)
Loss of external connectivity to central KDCs
…and some problems
The Ugly …

Fallback authentication is NTLM
KDCs don’ t speak NTLM
Some apps only speak NTLM
Problems integrating other operating systems (OS X, other?)

Summary

Works very well in certain scenarios
E.g. shared filestore for students
Reduced administrative overhead
Not appropriate for all environments
E.g. many services built on Active Directory (Exchange, Sharepoint, Web access to files etc.)

How do we set this up?

Full details are on the ITSS wiki:

wiki.oucs.ox.ac.uk/itss/KerberosADTrust
How do we set this up?

Check time is in sync (throughout domain and to ntp source)

See appendix for details!
How do we set this up?

2. Request a Kerberos principal from the OUCS Systems Development team (sysdev@oucs.ox.ac.uk)

krbtgt/FULL.AD.DOMAIN.NAME

krbtgt/STHUGHS.OX.AC.UK
krbtgt/ZOO.OX.AC.UK

How do we set this up?
How do we set this up?
How do we set this up?

4. Check time is in sync
How do we set this up?
5. On all domain controllers, member servers and workstations, install the Windows Support Tools and run:

ksetup /addkdc OX.AC.UK kdc0.ox.ac.uk
ksetup /addkdc OX.AC.UK kdc1.ox.ac.uk
ksetup /addkdc OX.AC.UK kdc2.ox.ac.uk

Or use a registry file/Group Policy (see wiki)
How do we set this up?
How do we set this up?

6. Create a one-way, outgoing, transitive trust between the Kerberos realm OX.AC.UK and the Active Directory forest

Use the password set in step 3.

How do we set this up?

How do we set this up?

7. Check time is in sync
How do we set this up?

8. Add a name mapping for AD account to the Kerberos realm
Format is oucs1234@OX.AC.UK
Note uppercase OX.AC.UK

How do we set this up?

How do we set this up?

9. Reboot workstation and log in

Demo

Contact details

bridget.lewis@ict.ox.ac.uk

adrian.parks@oucs.ox.ac.uk

Some links

ITSS Wiki:
wiki.oucs.ox.ac.uk/itss/KerberosADTrust

MIT:
Designing an Authentication System: A Dialogue in Four Scenes
web.mit.edu/kerberos/www/dialogue.html

Microsoft:
www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx

Kerberos: The Definitive Guide (Jason Garman/O’Reilly)

Appendix A î Utilities

2003 Resource Kit Utilities
Kerbtray (GUI)
Klist (command line)
Support Tools Utilities (from 2003 CD)
Ksetup (command line)
Ktpass (command line)

Kerbtray
Kerbtray displays tickets
Picture shows TGTs for ITSSCONFADDEMO.OX.AC.UK and OX.AC.UK
Kerbtray
Picture shows tickets for services in Active Directory Realm
Klist
Klist î as Kerbtray but command line
Support Tools
Ksetup
Set up realm information
E.g. set KDCs for a given realm
Ktpass
Manipulating principals
MIT Kerberos for Windows
web.mit.edu/kerberos/dist/
Another way of viewing tickets
Maintains its own ticket cache
Can import tickets from Microsoft cache
Some applications can use these tickets

Network Identity Manager
Appendix B î Additional Notes
Time must be within 5 minutes of KDC time
Logon may fail intermittently if logon allowed before network fully initialized (XP/2003)
Group Policy setting
Computer Configuration/ Administrative Templates/System/Logon
Enable setting “Always wait for network on computer startup or user logon”
Terminal Services Patch
support.microsoft.com/default.aspx?scid=KB;EN-US;902336

Short History of Time

All DCs sync to PDC emulator (automatic)
Member servers and workstations sync to Domain Controllers (automatic)
PDC emulator must be sync’ d to ntp source
Must update if you move PDC emulator role
w32tm /config /manualpeerlist: “ntpserver1 ntpserver2 ntpserver3” /syncfromflags:manual /reliable:yes /update
technet2.microsoft.com/windowsserver/en/library/ce8890cf-ef46-4931-8e4a-2fc5b4ddb0471033.mspx?mfr=true
Automated Account Creation
OUCS can provide nightly update of Oxford usernames and other information to each unit
www.oucs.ox.ac.uk/registration/card_data_2006.xml.ID=body.1_div.9
Use scripts to feed into Active Directory

Other notes of interest
Workstation authenticates too: problems for x-realm auth.
DC devolution î KDC patches available
Macs
eDir
preauth, timestamps, lifespan of tickets etc
Appendix C

Use Wireshark to observe the Kerberos exchange

A mobile single sign-on system
Master thesis 2006

Mats Byfuglien
Outline
Problem description
Project description
Research questions
Methods
Related work
The prototype
Results
Further work
Conclusion

Problem description
Most users today have a large number of passwords to manage
This often results in:
The passwords are written down
Easily guessable passwords are used
One password used on multiple accounts
This reduces the security passwords provide
Secure passwords is still a good authentication mechanism
SSO proposed as a way to improve password security

Project description
Today there are no mobile SSO solutions on the market supporting automated sign-ins.
Develop a functional prototype of a mobile SSO system that handles passwords and supports automatic sign in.
A mobile phone with a Java MIDlet handles the management of usernames and passwords
Bluetooth/USB unit connected to the PC
Conduct a user test
Security analysis to find what security measures should be implemented

Research questions
1. What types of single sign-on solutions are available?
2. How secure is the Bluetooth protocol for transferring sensitive data?
3. Is it possible to implement the proposed single sign-on concept?
4. What security mechanisms need to be in place to assure the security of this system?
5. How will this SSO concept be received by the users?
6. Will this SSO concept increase the users’ security level?
Methods
Literature study
Technical feasibility study
Develop the prototype
User test
Scenario
Survey
Interview
Security analysis
Adversary modeling
Other SSO solutions
A taxonomy lists 4 main categories:
Local pseudo SSO
SSO component is on the user’s computer
Proxy based pseudo SSO
The user authenticates once to the proxy and the proxy handles authentication to the services
Do not require any changes to the authentication systems
True SSO
User authenticates to Authentication Service Provider (ASP) once.
True SSO solutions are expensive and difficult to configure correctly
All systems must support the SSO solution
Local true SSO
Trused component
Proxy based true SSO
Kerberos

The prototype
Adversary modeling
Results from the security analysis
Four main issues were discovered:
Secure the Bluetooth channel
Secure protocol on top of Bluetooth protocol
Properly authenticate the devices
Digital certificates
Protect data stored on the mobile phone
Encryption
Split data on two devices
Confirm the integrity of software packages
Digitally sign the packages
Results from the user test
28 users participated
26 rated the system above average
19 would like to use the system daily
7 did not have an opinion, 2 would not use it
24 believes the system will improve their password management
Everyone wanted a backup solution

Further work
Implement the proposed security measures
Port the code to a smaller device
Implement a backup solution
Conduct a detailed security analysis when the security measures are implemented
Conduct a large scale user test
Allow users to test the system over time
Include a largerer number of participants
Conclusion
It is possible to implement the SSO concept
The system was well received by the users
The system will not provide better security then other SSO solutions
Mobility and easy to use functionality (no software or drivers needed) makes the system stand out
The solution might apeal to a different group then other SSO solutions
Will increase the security level of users who manages passwords manually
Enables the user to use more secure passwords
Questions?