Transcript 11-Redius_NAC_SSO

RADIUS, Network Access,
Single Sign On
RADIUS
• Remote authentication dial-in user service (RADIUS)
• AAA (authentication, authorization and accounting)
protocol for applications such as network access or IP
mobility
• The RADIUS server will also be notified if and when the
session starts and stops
– Billing
– Logging
• originally developed by Livingston Enterprises for their
PortMaster series of Network Access Servers
– Currently as RFC 2865 and 2866
– several commercial and open-source RADIUS servers exist
RADIUS Architecture
RADIUS Architecture
Authentication Flow
RADIUS Client
•
•
•
•
Theorem (for Java)
Livingstone (for c, unix)
Radiusclient (for c, unix)
Vopcom (for VC++)
RADIUS Server
•
•
•
•
•
Cistron
freeRADIUS
ICRADIUS
YARD RADIUS
GNU-radius
Standards
• IEEE
– 802.1x “Network port authentication”
– 802.1w “Spanning tree rapid convergence”
– 802.11e “Quality of service”
– 802.11f “Inter-access point protocol”
– 802.11i “Extended security”
• IETF
– RADIUS & AAA – authentication, authorization,
and accounting
– PPP Extensible authentication protocol (EAP)
– IPSec and IPSRA – IPSec and VPNs
What Is Network Access Control?
• A mechanism by which access to the network is
restricted to authorized entities, typically identified
by user IDs
• Once authenticated, user sessions need to be
authorized
– Authorization can include things like rate limiting, filters,
tunneling, etc
• To prevent connections from being hijacked, we
need per-packet authentication
– Per-packet authentication is based on a key derived
during the authentication process, linking each packet to
the identity claimed in the authentication
Wholesale Wireless Access
ISP A
RADIUS Proxy
AP A1
Public
802.11
Wireless
Networks
AP A2
Customer
RADIUS
Server
Internet
BIGCO
IP
AP A3
Carrier networks
802.11 Wireless
Access Points
Directory
Benefits of Wholesale Access
• Ubiquitous 802.11 wireless support
– Enables rapid deployment of IEEE 802.11
technologies in hotels, airports, malls
– Users can obtain wireless access using their
existing corporate accounts
• Easier to provide “backup” providers
• RADIUS provides accounting information
• Reduced carrying costs
– Leverage ISP capacity and aggregation
– Shared support burden and ISP expertise
Shared Use APs
ISP_A
Proxy
SSIDA
SSIDB
AP
RADIUS
Proxy
Shared Use
802.11 AP
Internet
SSIDC
Remote user
[email protected]
Customer
RADIUS
Server
BIGCO
IP
SSID: Service Set ID
Directory
Why Shared Use APs?
• Multiple providers are becoming the norm within airports
– Airlines are installing 802.11 networks for use in baggage
handling and roving ticket counters
– Multiple wireless ISPs often want to serve airport customers
• Radio interference is an issue
– In the US and Europe, 802.11b networks can support only 3 nonoverlapping channels; in France and Japan only one channel is
available
– Once the channels are utilized by existing APs, additional APs
will interfere and reduce performance
• 802.11 deployment in public spaces is expensive
– The cost of providing wireless access is inversely proportional to
infrastructure utilization
– More economical to build infrastructure and share it among
multiple providers than to build overlapping infrastructure
Single Sign On (SSO)
•
•
•
•
Introduction
SSO Approaches
Dealing with different SSO options
Focus:
– Perspective of an ISV/Developer who has to
deal with customers’ SSO environments.
Security Definitions
•
•
•
•
•
•
•
SSO – Single Sign On
Authentication
Authorization
Identity
Trusted source
Authentication factors
Portable identity
Traditional Authentication
System checks user id and
password against
application user database
User types Login id & Password
If both factors found in
database, user is now
authenticated for
application.
The Problem
• With the web, users no longer work with just one
application.
• Most users can’t remember all of their
passwords, get irritated having to re-type their
user id and password.
• System admins finding it challenging to maintain
user information.
• Security sacrificed because
– User Databases are not current
– Users keep their user ids and passwords written
down on their desk.
Conclusion…..
Application centric authentication
approaches no longer work in the web
world!
Single Sign on
• Allows a user to enter user id and
password (authentication factors) in one
place for all applications.
• Authentication based on user definitions
from a central database
• Eases users linking between applications
(one application is an instrument…many
applications working together is a
symphony)
The Answer ?
Login only Once
Corporate
Dir.
(LDAP,
RDMS,
etc.)
User authenticated to central SSO server
SSO Server
User authenticated
here…
And User
authenticated here..
And User
authenticated here
SSO Implications
• User has only to remember one user id
and password for the entire enterprise.
• System Admin only needs to maintain one
database.
• In short, the security, efficiency, and ease
of use improves for enterprises with SSO.
What is the magic behind SSO?
• There is no magic
– just a globally accessible user token
– From a trusted source
– Containing identifying information as well as
some descriptive attributes
• Most systems seem to use cookies or http
session attributes
Okay I am interested
What are my options?
SSO Options for the Enterprise
• Buy a commercial product (Netegrity, SAP,
Oracle, IBM, etc.)
• Use one of the Open Source options
appearing now (JOSSO)
• Write your own SSO server
• Do nothing, tell your boss that there are no
SSO standards so it is a waste to do
anything right now.
SSO Problems to solve
• Trust Me? I am a user in good standing.
• Supporting applications distributed across
the world.
• Weave applications developed by different
teams/companies together into a cohesive
unit
• Dealing with user logouts
SSO Configuration Questions
• Can the SSO Server:
– work outside of a firewall?
– Work with legacy applications?
• Early version of some servers actually required hard wiring to
the SSO vendors API
– Works with legacy applications without considerable
re-programming?
– Restrict access to different applications based on the
user definition in the SSO server?
– Support limited time access to a SSO controlled
application?
– Provide true security of the SSO Token as it moves
between applications?
SSO Options for the ISV?
• Hard code your application to the one
SSO Vendor who looks like a winner?
– Which one? IBM, SAP, Oracle, Netegrity,
JOSSO, etc.?
• Tell your marketing department that SSO
is a bad idea?
• Create a generic interface which will
support multiple SSO Vendors with a
minimal amount of effort and without
having to re-write your application.
The SSO Standards
• Currently, there are no standards
• Everyone seems to be using different
implementations
• Basing a whole product on a single
vendors SSO implementation is
dangerous ..Your current prospect will
always want an interface to a different
SSO server.
A Solution…
Write an Adapter which will support pluggable definitions…
•Home Grown
•JAAS
The Adapter’s Goals
• Support multiple flavors of
authentication/sso.
• Access to http session and Context
• Minimize impact to legacy client
application
Adapter Definition (GOF)
• Convert the interface of a class into
another interface clients expect. Adapter
lets classes/components work together
that couldn’t otherwise because of
incompatible interfaces.
Adapter Requirements/What are
the problems to solve?
• Validate SSO token from a trusted source
• Login/Authentication using an SSO supplied
login name/id
• Pass errors back to the portal application
• Coordinate application time outs
• Support the application’s logout handling
• Synchronize the user definitions with the SSO
Server/corporate directory.
• Access specific pages from the existing
application
The SSO Token
• Contains the subject identifier (login
name/id)
• Optional:
– Password or some other factor to verify the
user
– User information to update the legacy system
– Period of time that the user is valid on the
legacy application
• May or may not be encrypted
SSO Authentication
portal
SSO Token
Created for
user
• Token can be placed as a cookie or a session
attribute.
•Token should have information which can
be used to validate the token originated
from the trusted SSO server.
•The Token will be good for all applications
accessible by the portal.
User
Authenticates
To SSO
Server
•User verified against central corporate
directory.
•Can be a static page that the user knows
to login into
•Or can be a login form tied to a protected
group of pages.
SSO 1st Level Authentication
User
Request page
Enterprise
portal
Page accesses
Token
Validate
token
Contact
SSO Server
to verify
•ImportantSSO
to verify
that the token originates from a trusted source
Token
User
•Validations of
SSO
Token
can
use:
Token
can be
Created for
Authenticates
• PKI
Optional:
stored
as aSSO
cookie
user
To
How does
the
page
get
the
SSO
Token?
• IP Address recognition or
•SSO
Approach
as aServer
sessionthenrequires
• If a •generic
page
header
used
on
application,
add
a
Unique data formats containing
information
which
theattribute
client
application
to the client
SSO Token
checker
to see if
thedirect
user the
is user.
application
willwhen
need checking
to authenticate
and
directly contact
the SSO
authenticated.
•Effective date ranges.
server to verify the SSO
•If no page header , then try to leverage the existing
token and retrieve required
application page protection to check the SSO token.
attributes
•Very secure approach
SSO Authentication Workflow
•With this form of SSO, it can be possible
•Is
logout
now just
disconnect? Do you
for the portalPage
to jump
directly
intoa the
accesses
Contact
to
retain
the
application’s
session
Usermiddle of thewant
Validate
original
Tokenapplication with
SSO Server
information?
Request
page
token
Using the
original
session
management
of for
the the
application
•Since
application
was notlogic
written
SSO
minimal
work.
to verify
•Is
logout
a
logout
from
the
application,
create the
same
session
object
was
used
before
the
SSO
Project.
Server,
we
must
use
the
existing
authentication
•How is the page accessible?
butneed
user context
stays
intoexisting
the the
SSO
The SSO•Does
Token
live
inthe
session
memory
with
•The
objective
should
be
tologged
leave
the
thewill
page
data
toalong
server?
original properly
Session
marker.
authentication
module unmodified.
display?
•Isallowed
logout
aaccess
logouttofrom
application
and
•IfSSO
application
authentication
errors
are
Enterprise
•Is the
user
still
the
Token
User
server?
must Authenticates
be displayed to the user.
portal
page?encountered,
(expired
SSO
token)
CreatedSSO
forthey
be handled?
user•How should timeouts
To SSO
Server
Logout
From
app
Jump to
Desired page
Create user
session
Auth user on
application
SSO Error Handling
• Where to display the message?
– The Portal?
• How to communicate the message with the
application?
– The application?
• Security logging
Handling Synchronization
Corporate
Directory
(RDBMS, LDAP,
etc.)
User will SSO 1st Level
Authenticate against this data
store
User will authenticate
to the legacy
application using this
information
Application
User
Data store
If the user’s information does not exist in
the Application User Data store when they
try to connect then…..
Handling Synchronization
Strategies:
Corporate
Directory
(RDBMS, LDAP,
etc.)
•Ideal: Transfer data whenever adds or updates detected
in the Corporate Directory.
•If lots of data and limited bandwidth: Perform nightly,
weekly, or monthly updates
Some Questions:
•Will the data need transformation?
•How often does the data change?
•How Do either the corporate directory or the
legacy application need to be stopped to initiate copy?
•How much data has to move at one time?
•Is it possible to detect when data in the corporate directory
changes?
Application
User
Data store
The Design
SSO Use Cases
SSO Adapter Class Diagram
•Define a base class which contains all of the logic anticipated to be common for all of the
expected different SSO approaches you wish to support.
•Consider a factory of some sort if more than one SSO approach might be used per instance.
The Authentication Sequence
Diagram
Wrap Up
• SSO makes it easier for end users to
navigate heterogeneous Enterprise
systems.
• Lack of standards makes it hard for ISVs
to produce software which will work for all
potential customers.
• A Adapter based strategy can make it
possible to support the different types of
SSO Strategies as required.