Transcript Integrated Security Demo - Web Services Security ,Oracle 9iAS, PKI CSCI 5931 – Web Security Instructor: Dr.

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
1
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
2
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
3
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 signon 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
4
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
5
Agenda – Web Services single sign-on




Web Services Security
Single Sign-on in Web Services
Methods
Available Solutions
6
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
7
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
8
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
9
Simple Single sign on Scenario
10
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
11
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)
12
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.)
13
Advanced SSO-using SAML
14
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
15
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
16
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
17
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
18
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
19
Features of Single Sign-On (SSO)
Centralized authentication for web applications
• Secure
• Inexpensive
• PKI support
• 3rd party integration
20
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)
21
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 authentication:Typically relies on an LDAPcompliant directory. In this case, the Login Server binds to the LDAPcompliant directory, then looks up the user credentials stored there.
External Authentication includes LDAP and Database Authentication
and any others that may be custom-developed
22
Functional Overview of Oracle9i AS SSO
Initial Authentication
1.
User accesses Partner App A which determines user
isn’t authenticated.
2.
App A redirects user to SSO server.
3.
SSO server prompts user to give username and
password.
4.
SSO server verifies password and sets SSO cookie
on client machine for authentication by Partner App.
5.
SSO credentials may be stored in external server.
6.
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 client’s 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.
23
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 user’s 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.
24
Functional Overview of Oracle9i AS SSO
Authentication to External Applications
4
1.
Client requests access to external App. is
redirected to SSO server.
2.
SSO server prompts client for username and
password.
3.
Clients username and password are
encrypted and sent to External App for
authentication.
4.
After external app verifies client, SSO
server sets SSO cookie on client and
redirects client to App.
5.
It sends a copy to the App for verification.
5
The SSO server uses external App’s
verification module to authenticate user and
sets the SSO cookie on the client.
25
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.
26
Oracle 9i AS Security Architecture
27
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.
28
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.
29
PKI Technology and Architecture
30
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.
31
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.
32
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.
33
References
o
o
o
o
http://www.certicom.com/pdfs/whitepapers/Trustpoint_PKI.
pdf
http://www.articsoft.com/wp_pki_intro.htm
http://technet.oracle.com/sample_code/deploy/security/files/
ssosecurity/Readme.html
http://technet.oracle.com/sample_code/deploy/security/files/
ssosecurity/Readme.html
34
Wrapping Up…
35