RADIUS Network Access Single Sign On RADIUS Remote

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 Port. Master 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 free. RADIUS ICRADIUS YARD RADIUS GNU-radius

Standards • IEEE – 802. 1 x “Network port authentication” – 802. 1 w “Spanning tree rapid convergence” – 802. 11 e “Quality of service” – 802. 11 f “Inter-access point protocol” – 802. 11 i “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 US I D A R Public 802. 11 Wireless Networks AP A 2 S DI U RA AP A 1 ISP A RADIUS Proxy Customer RADIUS Server Internet BIGCO IP AP A 3 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 US I D A R SSIDA SSIDB AP S DI U RA US I D A R RADIUS Proxy Shared Use 802. 11 AP Internet SSIDC Remote user fred@bigco. com 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. 11 b 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 1 st Level Authentication User Request page Enterprise portal Page accesses Token Validate token Contact SSO Server to verify • Important SSO to verify that the token originates from a trusted source Token User • Validations Created of SSO Token can use: Token can be for Authenticates • PKI Optional: stored as a. SSO cookie user To How does the page get the SSO Token? • IP Address recognition or • SSO Approach requires as a. Server session • If a generic page header used on application, then which add a the client • Unique data formats containing information theattribute client application to SSO Token checker when checking to see if the user is application will need to authenticate and direct the user. 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 • Isportal logout just a disconnect? Do possible for. Page the tonow jump directly accesses Contact you want to retain the application’s Userinto the middle Validate of the original application Token SSO Server session information? Request page token Using the original session management logic of the application • Since application was not written for the SSO with minimal work. to verify • Is logout a logout from the application, create the same session object was used before the SSO Project. Server, must use the existing authentication • How is the we page accessible? theshould stays logged into the SSO - The SSO Token willbut live inuser session memory along with the • The be to leave existing • Does theobjective page need data context to the server? originalproperly Session marker. authentication module unmodified. display? • Is allowed logout aaccess logouttofrom and • If. SSO application authentication errors are Enterprise • Is the user still the application Token User server? encountered, they must. Authenticates be displayed to the portal page? (expired SSO token) Created. SSO for 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 1 st 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. ) Some Questions: Nee • 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 d to cop y da t to a a from ppli cati corpora on te dir • 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.