Data and Applications Security Developments and Directions

1
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

2
Outline

• Single Sign-On
• Reference http//en.wikipedia.org/wiki/Single_sig
  n-on
• Federated Identity Management
• Reference http//en.wikipedia.org/wiki/Federated_
  identity
• Open ID, Information Card
• http//en.wikipedia.org/wiki/OpenID
• http//en.wikipedia.org/wiki/Information_Card

3
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

4
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.

5
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.

6
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.

7
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.

8
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.

9
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.

10
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.

11
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.

12
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 Novells Bandit
  project).