Building AAI

1
Building AAI

• Miroslav Milinovic
• University Computing Centre SRCE,Universty of
  Zagreb, Zagreb, Croatia
• miro_at_srce.hr
• 9th CEENet Workshop on Network Technology,
  Budapest, Hungary, August 2004

2
Contents

• AAI Model
• AAI for Network Access
• Inter-NREN Roaming
• SSO

3
AAI Model
Home
Resource
organisation
owner
AuthN system
access
authorisation
rights
attributes
directory
delivery
resource
authorisation attributes
Access
control
AuthN
acess request
user
4
AAI Needs Challenges

• identify the needs
• resources /resource owners
• home organisations
• users
• challenges
• authentication at the network level(how users
  can get access to the Internet from the
  institutions they are visiting)
• secure access to remote and/or local
  resources(once users obtain access to the
  network)

5
AAI Expectations

• The AAI should
• minimise the work of the system administrators,
• be scalable to work with many users,
• be standards based
• be secure,
• should reduce to the minimum the need to install
  new software on end user systems.
• In a highly distributed and decentralised
  environment, it is important that the user
  administration is equally distributed

6
AAI Network Access

• For access control to the network there are in
  essence three approaches being used in the
  academic world
• based on web-based access in combination with a
  RADIUS-infrastructure
• based on VPNs
• based on 802.1X, the IEEE-standard for port-based
  authentication, in combination with a
  RADIUS-infrastructure.

7
Web Based (Web Redirect)
8
VPN Based Solution
http//www.switch.ch/mobile
9
802.1x Based Solution
http//www.eduroam.nl/
10
AAI Mobility

• A basic aspect of this model of mobility is to
  develop and deploy inter-operable Authentication
  and Authorisation infrastructures (AAI) and
  services, which would allow users to move between
  institutions using wired or wireless systems.
• The harmonisation of e-identities and
  information relevant to authorisation decisions
  is necessary.

11
Examples

• AAI for network access (CARNet network)
• network access from student dormitories (StuDom
  project, Srce)
• Inter-NREN roaming (TERENA, TF-Mobility)

12
AAI for Network Access
dial-up access wired wireless from
dormitories wireless form selecetel
locations Inter-NREN roaming
ID user.realm (IDuser.realm_at_hr)
(Lucent Navis) proxy radius server(s) central
LDAP server for backup
around 200 home orgs over 100000 registered
users SW FreeRadius OpenLDAP
13
Virtual identity

• home orgs register users and provide them with
  the virtual identity (username / password)
• username consist of two parts
• unique user identifier (e.g. unix account login)
• unique institution identifier (e.g. home orgs
  domain name)
• an example miro.srce
• for inter-NREN roaming _at_hr extension has to be
  used
• miro.srce_at_hr

14
Users device (client)

• Any device with EAP supplicant (client) for AuthN
• some of available clients
• MS Windows 2000 i MS Windows XP
  secureW2http//www.alfa-ariss.com/
• LINUX/UNIX - http//www.open1x.org/
• Win95, Win98, Win98 SE, MAChttp//www.mtghouse.co
  m/http//www.funk.com/

15
StuDom AA(A)
16
StuDom AA(A) system - technology

• Authenticated and Authorized wired and wireless
  access to CARNet network using IEEE 802.1X
• Username/Password based Authentication
• User Mobility connection from any part of the
  StuDom Network
• No simultaneous network access allowed
  connection to only one work place at the time
  using same username/password
• Switch uses EAPOL and EAP-TTLS for the exchange
  of authentication messages with a client and
  Radius server

17
StuDom AA(A) - implementation

• Each user has to be authenticated or recognised
  as a member of Croatian academic and research
  community
• Each user has to be authorised for the use of the
  StuDOM service (network access)
• Adding auditing element as a way of supervision
  of the StuDOM service usage

18
StuDom AA(A) - implementation

• Authentication uses the existing infrastructure
  of distributed LDAP directories in the Croatian
  academic and research community gt user is
  authenticated via appropriate LDAP record on the
  LDAP server of the corresponding home institution
• Authentication procedure
• I) Appropriate client program (supplicant) takes
  user credentials (username in the form of
  UserID.Realm) and sends it to the access unit
  (switch, wireless access point,)
• II) access unit forwards request in the form of
  EAP-TTLS packet to the Radius server at the
  location of the access unit (local Radius server)

19
StuDom AA(A) - implementation

• Authentication procedure (contd.)
• III) local Radius server forwards received
  packet to the Radius proxy server, which on the
  basis of the realm redirects the packet to the
  corresponding Radius server of user home
  institution
• IV) Home institution Radius server authenticate
  user comparing received credentials with the
  appropriate LDAP record in LDAP server of the
  home institution
• V) depending whether the authentication is
  succesfull or not, local Radius server sends an
  Accept or Reject Radius protocol message to the
  Radius server at the location of the access unit,
  through the proxy Radius server

20
StuDom AA(A) - implementation

• Authorizationis reduced to checking the number
  of simultaneous connections user might want to
  achieve at the location in question (at this
  moment)
• could be more complex, depending on the needs of
  the owner of the network resource the user is
  trying to access (e.g. for security purposes
  additional access limit based on the pre-defined
  MAC address, etc.)
• Authorization procedure
• done at the location of the access unit, because
  this is the place of the owner of the service
  user is trying to access
• After succesfull authorization process, the user
  is given the right to access the network (Radius
  at the location of the access unit sends Radius
  protocol message Accept)
• Unsuccesfull AA process blocks port on the switch

21
StuDom AA(A) - implementation

• Auditing after established user connection,
  access unit sends auditing information to the
  local Radius server, which saves it into the
  MySQL database

22
StuDom in numbers

• SC Zagreb, Student dormitory 'Stjepan Radic'
• 863 networked work places covered 24,3 of
  the total
• SC Zagreb, Student dormitory 'Cvjetno naselje'
• 455 networked work places
• covered 27,8 of the total
• SC Zagreb, Student dormitory 'Lacina 176
  networked work places covered 36,5 of the total
• SC Osijek, Student dormitory 269 networked work
  places
• covered 100

23
Inter-NREN roaming

• Federated AAI
• Architectural concepts
• User data (attribute sets) syntax and semantics
• Protocols, both for exchanging authentication
  data and performing authorisation decisions
• Trust building techniques
• Privacy preservation techniques
• Administration and accounting tools in a
  federated space
• Interoperability assessment
• Interaction with AAIs in other communities
  Grids, Internet2,...
• Interaction with commercial AAIs

24
Requirements for inter-NREN roaming

• Major requirements
• scalability of the proposed solution must be
  maintained
• administrative overhead must be minimised
• required security must be maintained for all
  partners in the process
• Minor requirements
• usability must be good for all needed/used
  platforms.
• accountability and logging functionality must be
  provided to track abuse
• Regulation/Legislation issues
• (proposed by TERENA TF-Mobility)

25
Possible Solutions

• visiting user access to the visited institution
  network
• visiting user access to the home institution
  network (the mechanics are in place for AAA
  validation)

26
Inter-NREN roaming
http//www.terena.nl/tech/task-forces/tf-mobility/
eduroam.html
27
Current status

• Characteristics identified as
• 802.1X - The future, easy to scale, secure but
  cutting edge, thus expensive
• VPN - Widely available, expensive, secure hard
  to scale
• Web based cheap, widely available, easy to
  scale, but not secure.
• Preliminary selection for inter-NREN roaming
• no national solution meets all the requirements
• not to consider the following
• Local VPN access
• PKI
• An architecture that supports the various
  national solutions is needed, a three stream
  approach is recommended

28
Integration?

• 802.1X
• Secure SSID
• RADIUS
• Web-based captive portal
• Open SSID
• RADIUS
• PKI-based
• Open SSID
• No RADIUS

29
What is Single-Sign On?

• SSO
• Authenticate once, access multiple (network or
  application) services

30
Short term 2 separate SSO infrastructures

• 1 for network access aka roaming
• 1 for application access web based

31
Short-term Network SSO

• Access to the same type of network (e.g. WiFi)
  with a single account (horizontal roaming)
• Access to different networks (e.g. WiFi and GPRS)
  with a single account (vertical roaming)requires
  mobile IP
• Presence information very useful

32
Short-term Application SSO

• Thru a web login or webISO server
• Embedded in an AAI environment
• authN services
• authZ services (roles, attrs, etc.)
• Easy part within a single domain
• Challenging part across domain federated
  identity services needed

33
Long-term SSO

• SSO across network and application domains
• How?
• Directions
• Same authN methods for 1X and webISO
• Communication between network device and webISO
  server required

34
Omnipresent SSO?
AAI components
App servers
webISO
?
Supplicant
RADIUS server Institution B
RADIUS server Institution A
Authenticator
User DB
User DB
guestmiro.srce_at_hr
Internet
signalling
Employee VLAN
Guest VLAN
data
Central RADIUS Proxy server
Student VLAN
proposed by Surfnet team
35
Contents

• AAI Model
• AAI for Network Access
• Inter-NREN Roaming
• SSO