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

AP A3AP A3

AP A2AP A2

Public802.11WirelessNetworks

Internet BIGCO

IP

802.11 WirelessAccess Points

Carrier networks

Customer RADIUS Server

ISP ARADIUS Proxy

AP A1AP A1 RA

DIU

S

RA

DIU

SRADIU

S

RADIUS

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

Internet BIGCO

IP

Shared Use802.11 AP

Remote userfred@bigco.com

Customer RADIUS Server

SSIDA

APAP

RA

DIU

S

RA

DIU

S

RADIUS

RADIUS

Directory

SSIDB

SSIDC

RADIUSProxy

RADIUS

RADIUS

ISP_AProxy

SSID: Service Set ID

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

non-overlapping 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

User types Login id & Password

System checks user id and password

against application user database

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

SSO Server

User authenticated to central SSO server

User authenticated

here…

And User authenticated

here..

And User authenticated

here

CorporateDir.

(LDAP, RDMS,

etc.)

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

portalUser

AuthenticatesTo SSOServer

•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 protectedgroup of pages.

SSO Token Created for

user

• Token can be placed as a cookie or a sessionattribute.•Token should have information which canbe used to validate the token originatedfrom the trusted SSO server.•The Token will be good for all applications accessible by the portal.

SSO 1st Level Authentication

Enterprise portal

Page accesses Token Validate

token

Contact SSO Server

to verify

User Authenticates

To SSOServer

SSO Token Created for

user

User Request page

How does the page get the SSO Token?• If a generic page header used on application, then add a SSO Token checker when checking to see if the user is authenticated.•If no page header , then try to leverage the existing application page protection to check the SSO token.

Token can be stored as a

cookie or as a session

attribute

•Important to verify that the token originates from a trusted source

•Validations of SSO Token can use:• PKI• IP Address recognition• Unique data formats containing information which the clientapplication will need to authenticate and direct the user.•Effective date ranges.

Optional: •SSO Approach requires the client application to directly contact the SSO server to verify the SSO token and retrieve required attributes•Very secure approach

SSO Authentication Workflow

Enterprise portal

Page accesses Token Validate

token

Contact SSO Server

to verify

Auth user onapplication

Create usersession

Jump toDesired page

Logout From app

User Authenticates

To SSOServer

SSO Token Created for

user

User Request page•Since application was not written

for the SSO Server, we must use the existing authentication

•The objective should be to leave the existing authentication module unmodified. •If application authentication errors are encountered, they must be displayed to the user.

Using the original session management logic of the application create the same session object was used before the SSO Project. - The SSO Token will live in session memory along with the original Session marker.

•Is logout now just a disconnect? Do you want to retain the application’s session information?•Is logout a logout from the application, but the user stays logged into the SSO server?•Is logout a logout from application and SSO server?•How should timeouts be handled?

•With this form of SSO, it can be possible for the portal to jump directly into the middle of the original application with minimal work.•How is the page accessible? •Does the page need data context to properly display?•Is the user still allowed access to the page? (expired SSO token)

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

Application User

Data store

If the user’s information does not exist inthe Application User Data store when theytry to connect then…..

User will SSO 1st Level Authenticate against

this data store User will authenticate to

the legacy application using this information

Handling Synchronization

Corporate Directory

(RDBMS, LDAP,etc.)

Application User

Data store

Need to copy data from corporate dir

to applicationSome 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 directorychanges?

Strategies:•Ideal: Transfer data whenever adds or updates detectedin the Corporate Directory.•If lots of data and limited bandwidth: Perform nightly, weekly, or monthly updates

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