Integrated Security Demo - Web Services Security ,Oracle 9iAS, PKI

1
Integrated Security Demo - Web Services
Security ,Oracle 9iAS, PKI
CSCI 5931 Web Security Instructor Dr. Andrew
Yang Team Web Warriors Rohan Bairat, Shashank
Dhond, Mohd A Azeem 23 rd April 2003
2
Single Sign on

• In any client/server relationship, single sign-on
  is a session/user authentication process that
  permits a user to enter one name and password in
  order to access multiple applications
• In e-commerce, the single sign-on is designed to
  centralize consumer financial information on one
  server - not only for the consumer's convenience,
  but also to offer increased security by limiting
  the number of times the consumer enters credit
  card numbers or other sensitive information used
  in billing
• Two Types of Single Sign-on
• Web Single Sign-on
• Legacy Single Sign-on

3
Web Single Sign-on

• The Web is made up of portals which act as
  gateways to many layers of web sites
• Earlier Web security was based on protecting
  URLs, not applications and SSL was suppose to be
  a complete solution
• As applications and databases started being
  attached to the backend of URLs SSL limitations
  showed up.
• SSL is CPU intensive cannot create a user
  experience
• SSL only can work between two endpoints
• A single sign-on solution will write the
  front-end authentication through to a central
  management console on the backend, and share this
  information between applications for the extent
  of the user session

4
Legacy Single Sign-on

• Legacy single sign-on enables smooth navigation
  of the various applications on an intranet
  through one authentication session
• Industry analysts refer to legacy single sign-on
  as employee single sign-on
• It conceptually uses the same authentication and
  authorization architecture structure as Web
  single sign-on, except a portal is not part of
  the front-end picture

5
More on Single Sign-on

• Single sign-on and password synchronization are
  two different things
• A password synchronization system does is
  distribute and synchronize a main password to
  other systems
• true single sign-on products that offer advanced
  and sophisticated capabilities, a user can
  actually have different passwords for every
  application
• The single sign-on server stores these passwords
  in a protected database, and makes them available
  to the user upon login
• Players in Single Sign-on
• Entrust, Evidian, Netegrity, and RSA Security.
  All three of these products can be run on UNIX
  platforms, and offer rules-based capabilities,
  roles-based capabilities, and LDAP compliancy

6
Agenda Web Services single sign-on

• Web Services Security
• Single Sign-on in Web Services
• Methods
• Available Solutions

7
Web Services Security

• Different companies had posted their own
  standards for securing web services
• IBM WS Security
• The Java WSDP Security
• The Liberty Alliance SSO Architecture

8
Single sign-on in Web Service

• Single sign-on security architecture is to shift
  the complexity of the security architecture to
  the called SSO service
• In the SSO architecture, all security algorithms
  are found in the single SSO server which acts as
  the single and only authentication point for a
  defined domain
• SSO approach can be used for authentication
  /registration a user has to sign-on only once
• The SSO server can be a Web service

9
The Simple SSO Scenario

• Modus Operandi
• The authenticated party first calls the SSO
  server and requests the authentication token that
  identifies it in the particular domain
• Token is available only when party provides the
  correct authentication credentials
• username/password
• Certificates
• Other methods
• The SSO server performs a validation of the
  users' credentials using the underlying security
  infrastructure
• The Token is issued to the user
• Token is a unique identification for the user in
  Simple SSO Scenario

10
Simple Single sign on Scenario
11
Advantage

• Encapsulation of the underlying security
  infrastructure in the SSO server
• Implementation, deployment and maintenance are
  much easier as all communicating parties in the
  distributed system don't need to individually
  implement all of the security features and
  mechanisms.
• The SOAP interface to the SSO server makes the
  SSO architecture universal
• The SSO server enhances security of the whole
  system as the security credentials don't need to
  be passed around
• Authentication can be performed outside the
  security domain but security credentials stay
  within a security domain

12
Advanced SSO-using SAML

• In the previous simple SSO scenario each time the
  user is challenged for identity verification
• In this approach the token itself contains
  valuable security information that allows
  validation without having to call the SSO server
  each time
• The token contains the authentication or
  authorization information signed by SSO server
• There is a new standard for exchanging
  security-related information in XML called
  Security Assertions Markup Language (SAML)
  (developed by OASIS)

13
Security Assertions Markup Language

• SAML defines the protocol by which the service
  consumer issues the SAML request and the
  so-called SAML authority returns the SAML
  response with assertions
• The security information described by SAML is
  expressed in the form of assertion statements
  about security subjects (e.g. users, machines or
  services)
• Assertions
• The Authentication statement informs about the
  authentication of a particular subject in a
  specific time and scope.
• The Authorization decision allows or denies a
  subject access to a specific resource.
• The Attributes further qualify the subject (e.g.
  credit line info, citizenship etc.)

14
Advanced SSO-using SAML
15
Agenda - Oracle 9iAS single Sign-On

• Overview of Single Sign-On
• Web Single Sign-On
• Legacy Single Sign-On
• Features of Single Sign-On
• SSO Components Application Types
• SSO Authentication Methods
• Functional Overview of Oracle 9i AS SSO
• Oracle 9i AS Security Architecture

16
Overview of Single Sign on

• In any client/server relationship, single sign-on
  is a session/user authentication process that
  permits a user to enter one name and password in
  order to access multiple applications
• In e-commerce, the single sign-on is designed to
  centralize consumer financial information on one
  server - not only for the consumer's convenience,
  but also to offer increased security by limiting
  the number of times the consumer enters credit
  card numbers or other sensitive information used
  in billing
• Two Types of Single Sign-on
• Web Single Sign-on
• Legacy Single Sign-on

17
Web Single Sign-on

• The Web is made up of portals which act as
  gateways to many layers of web sites
• Earlier Web security was based on protecting
  URLs, not applications and SSL was suppose to be
  a complete solution
• As applications and databases started being
  attached to the backend of URLs SSL limitations
  showed up.
• SSL is CPU intensive cannot create a user
  experience
• SSL only can work between two endpoints
• A single sign-on solution will write the
  front-end authentication through to a central
  management console on the backend, and share this
  information between applications for the extent
  of the user session

18
Legacy Single Sign-on

• Legacy single sign-on enables smooth navigation
  of the various applications on an intranet
  through one authentication session
• Industry analysts refer to legacy single sign-on
  as employee single sign-on
• It conceptually uses the same authentication and
  authorization architecture structure as Web
  single sign-on, except a portal is not part of
  the front-end picture

19
More on Single Sign-on

• Single sign-on and password synchronization are
  two different things
• A password synchronization system does is
  distribute and synchronize a main password to
  other systems
• The single sign-on server stores these passwords
  in a protected database, and makes them available
  to the user upon login
• Players in Single Sign-on
• Entrust, Evidian, Netegrity, and RSA Security.
  All three of these products can be run on UNIX
  platforms, and offer rules-based capabilities,
  roles-based capabilities, and LDAP compliancy

20
Features of Single Sign-On (SSO)

• Centralized authentication for web applications
• Secure
• Inexpensive
• PKI support
• 3rd party integration

21
SSO Components

Applications - Partner -
External Centralized SSO Server
Verifies SSO password Sets SSO cookie at
client External app username/password
store Username/Password managed in LDAP
directory Oracle Internet Directory
(OID) Other LDAPv3 directory requires
OID gateway Users provisioned through
OID Delegated Administrative Services
(DAS)

22
SSO Authentication Methods

• Oracle9iAS Single Sign-On uses one of these
  authentication methods
• Local user authentication Uses a lookup table
  within the Login Server schema. This table
  contains user name, password, Login Server
  privilege level, and other auditing fields for
  the user. The incoming password is one-way hashed
  and compared to the entry in the table.
• External repository authenticationTypically
  relies on an LDAP-compliant directory. In this
  case, the Login Server binds to the
  LDAP-compliant directory, then looks up the user
  credentials stored there. External Authentication
  includes LDAP and Database Authentication and any
  others that may be custom-developed
•  

23
Functional Overview of Oracle9i AS SSO
Initial Authentication

• User accesses Partner App A which determines user
  isnt authenticated.
• App A redirects user to SSO server.
• SSO server prompts user to give username and
  password.
• SSO server verifies password and sets SSO cookie
  on client machine for authentication by Partner
  App.
• SSO credentials may be stored in external server.
• SSO server redirects user to partner App and also
  provides the partner App with an encrypted copy
  of the SSO cookie for it to verify the clients
  identity.
• 7. Partner App A sets its own cookie after
  verifying the client with the copy of the SSO
  cookie obtained from the SSO server.

24
Functional Overview of Oracle9i AS SSO

• Authentication to partner applications
• Once a user has been authenticated and an SSO
  cookie has been set, Oracle 9i AS SSO directs
  the user back to the partner application and
  includes an encrypted token which contains the
  users identity in the partner application URL.
  Then the token is encrypted in a key which is
  shared only by Oracle 9i AS SSO and the partner
  application. This assures the partner application
  that the token is authentic and was created by
  Oracle 9i AS SSO.

25
Functional Overview of Oracle9i AS SSO
Authentication to External Applications

• Client requests access to external App. is
  redirected to SSO server.
• SSO server prompts client for username and
  password.
• Clients username and password are encrypted and
  sent to External App for authentication.
• After external app verifies client, SSO server
  sets SSO cookie on client and redirects client to
  App.
• It sends a copy to the App for verification.
• The SSO server uses external Apps verification
  module to authenticate user and sets the SSO
  cookie on the client.

4
5
26
Functional Overview of Oracle9i AS SSO

• LDAP integration
• Directories supporting the Lightweight
  Directory Access Protocol (LDAP) are increasingly
  used as a single source of enterprise-wide
  information about users.
• Oracle9iAS SSO verifies usernames and passwords
  using OID. When a user submits username and
  password as part of the initial authentication,
  Oracle9iAS SSO compares the username and password
  with that maintained in OID. If the comparison
  succeeds, username and password are considered to
  be verified.

27
Oracle 9i AS Security Architecture
28
What is PKI?

• PKI is a security architecture that has been
  introduced to provide an increased level of
  confidence for exchanging information over an
  increasingly insecure Internet.
• PKI is based on the use of digital certificates
  that allow users to verify the identity of the
  person or institution that they're communicating
  with, and to digitally sign transactions.

29
What PKI offers

• A certificate-based system that provides
• Authentication to verify the identity of the
  sender and the recipient.
• Data integrity to verify that information is
  received unaltered from the sender.
• Data confidentiality to ensure that sensitive
  information does not fall into the wrong hands.
• Non-repudiation to ensure that transactions are
  legally binding, protecting your business from
  fraud.

30
PKI Technology and Architecture
31
The Primary Technical Components of PKI

• End Entity Application (EE).
• Registration Authority (RA) It performs the
  necessary checks to make sure the person
  requesting the certificate is the same that
  he/she claims to be.
• Certification Authority (CA) Issues and
  verifies certificates.
• PKI directories They are databases that are
  X.500/LDAP compliant. They contain certificates
  in X.500/LDAP in th X.509format, and that they
  provide specific search Facilities.

32
How PKI can be used with SSO

• SSO layer of the application is built on top of a
  PKI layer.
• PKI handles the LDAP directory part. The SSO
  server refers to the Certificate Authority (CA)
  to verify the credibility of the user and to
  authenticate his certificate.
• Thus, in a SSO implemented with PKI
• The user first obtains a certificate from the CA
  using PKI.
• The user then calls the SSO server, provides the
  SSO server with its certificate and requests for
  a token identifying its domain.

33
How PKI can be used with SSO

• The SSO server refers to the CA to verify the
  users certificate.
• The CA checks its PKI directory to verify the
  certificate provided by the SSO server.
• If the certificate checks out to be good the SSO
  server issues the user with a token.

34
References

• http//www.certicom.com/pdfs/whitepapers/Trustpoin
  t_PKI.pdf
• http//www.articsoft.com/wp_pki_intro.htm
• http//technet.oracle.com/sample_code/deploy/secur
  ity/files/ssosecurity/Readme.html
• http//technet.oracle.com/sample_code/deploy/secur
  ity/files/ssosecurity/Readme.html

35
Wrapping Up