Transcript JRAX/SA3: Title of Activity

Connect. Communicate. Collaborate
Federated peering the NREN way:
eduGAIN and eduroam
Diego R. Lopez (RedIRIS)
Klaas Wierenga (SURFnet)
Contents
•
•
•
•
Connect. Communicate. Collaborate
The drivers for (con-)federations (Diego)
The eduroam case (Klaas)
The eduGAIN case (Diego)
The holy grail aka universal single signon aka DAMe
(Klaas)
Connect. Communicate. Collaborate
The drivers for con-federations
Connect. Communicate. Collaborate
The eduroam case
Confederation avant-la-lettre
The goal of eduroam
Connect. Communicate. Collaborate
• “open your laptop and be online”
• To build an interoperable, scalable and secure
authentication infrastructure that will be used all
over the world enabling seamless sharing of
network resources
eduroam concepts
•
•
•
•
Based on reciprocal (free) access
NREN community
Authentication at home
Authorisation at visited institution
Connect. Communicate. Collaborate
eduroam: ubiquitous network
access
Connect. Communicate. Collaborate
Supplicant
Authenticator
(AP or switch)
RADIUS server
RADIUS server
User
DB
University A
Gast
University B
SURFnet
piet@university_b.nl
Employee
VLAN
signalling
data
Commercial
VLAN
Central RADIUS
Student
VLAN
Proxy server
•
Trust based on RADIUS plus policy
documents
•
802.1X
•
(VLAN assigment)
User
DB
A general model for
eduroam interactions
Connect. Communicate. Collaborate
Tue Oct 10 00:05:15 2006: DEBUG: Packet dump:
Oct
10 00:17:32 2006:
*** ReceivedTue
from
145.99.133.194
portDEBUG:
1025 .... Handling request with Handler 'TunnelledByTTLS=
1, Realm=/guest.showcase.surfnet.nl/i'
Code:
Access-Request
Identifier: 1 Tue Oct 10 00:17:32 2006: DEBUG: Deleting session for [email protected]
case.surfnet.nl, 145.99.133.194,
Authentic: k<145><206><152><185><0><0><0><249><26><0><0><208>D<1><16>
Attributes: Tue Oct 10 00:17:32 2006: DEBUG: Handling with Radius::AuthFILE: SC-GUEST-ID
Tue Oct
10 00:17:32 2006: DEBUG: Reading users file /etc/radiator/db/showcase-gu
User-Name
= "[email protected]"
est-users = 145.99.133.194
NAS-IP-Address
Tue Oct 10=00:17:32
2006: DEBUG: Radius::AuthFILE looks for match with Klaas.Wie
Called-Station-Id
"001217d45bc7"
[email protected]
[[email protected]]
Calling-Station-Id
= "0012f0906ccb"
Tue
Oct
10
00:17:32
2006: DEBUG: Radius::AuthFILE ACCEPT: : Klaas.Wierenga@guest
NAS-Identifier = "001217d45bc7"
.showcase.surfnet.nl
[[email protected]]
NAS-Port
= 55
Tue Oct
10 00:17:32 2006: DEBUG: AuthBy FILE result: ACCEPT,
Framed-MTU
= 1400
Tue Oct 10
00:17:32 2006: DEBUG: Access accepted for [email protected]
NAS-Port-Type
= Wireless-IEEE-802-11
se.surfnet.nl
EAP-Message
= <2><0><0>-<1>[email protected]
Tue
Oct
10
00:17:32
2006: DEBUG: Returned TTLS tunnelled Diameter Packet dump:
Message-Authenticator
= <27>`Code:
Access-Accept
y<208><232><252><177>.<160><230><177>I<218
><243>\
RADIUS@visited
Resource (AP)
RADIUS + TLS Channel(s)
RADIUS@home
Id Repository
eduroam Hierarchy
Connect. Communicate. Collaborate
(virtual) eduroam root
European root
..
APAN root
.nl
.ac.uk
...
.dk
.hr
...
.es
..
(America’s root)
.au
.edu
...
...
.cn
.us
eduroam confederations
•
•
•
Connect. Communicate. Collaborate
Regions have their own stage of development and pace
Regions have their own regional policies (with delegation to national federations)
Policies will be aligned as much as possible
The European eduroam
policy
Connect. Communicate. Collaborate
• Mutual access
• Home institutions are/remain responsible for their users
abroad
• Members are European NRENs
• Members guarantee required security levels by their
participants
• Members promote eduroam in their countries
• European eduroam may peer with other regions
National policies
Connect. Communicate. Collaborate
• Mutual access
• Members are connected institutions
• Home institution is/remains responsible for its users
behaviour.
• Home institution is responsible for proper user
management
• Home and visited institution must keep sufficient logdata
• Appropriate security levels
Limitations
Connect. Communicate. Collaborate
• Authentication = authorisation
• Hierarchical trust establishment AND hierarchical routing of
access requests
• Transitive trust
• No dynamic trust establishment
• Use of UDP
• Use of shared secrets
eduroam-ng
Connect. Communicate. Collaborate
• After evaluating Diameter, RadSec and DNSROAM:
• Introduction of RadSec
– TCP instead of UDP
– TLS between RADIUS-servers instead of shared
secrets
• Possibly at later stage introduction of DNSROAM
– Support for direct peer interaction
– How about firewalls / access lists?
• Eventually Diameter?
Connect. Communicate. Collaborate
The eduGAIN case
The Goal of AAI within GN2
Connect. Communicate. Collaborate
• To build an interoperable authentication and
authorisation infrastructure that will be used all
over Europe enabling seamless sharing of escience resources
• We started from
– Scattered AAI (pilot) implementations in the EU and
abroad
– The basic idea of federating them, preserving hardwon achievements
eduGAIN Concepts
Connect. Communicate. Collaborate
• Confederations and dynamic trust establishment
• A confederation is a loosely-coupled
cooperating identity federations
set
of
– Identity management and authentication-authorisation
must be properly handled by the participating federations
• Trust must be dynamically established
– Members of a participant federation do not know in
advance about members in the other federations
– Federations are loosely coupled by the confederation
Dynamic Trust
Connect. Communicate. Collaborate
• Provided through three basic elements
– The Metadata Service (MDS)
– A Public Key Infrastructure (PKI)
– A set of naming policies for the eduGAIN components
• Because of their very nature, trust links across
eduGAIN are weaker than those inside
participating federations
The eduGAIN Components
Connect. Communicate. Collaborate
• Bridging Elements (BE)
– Interconnection points
– Federation-wide (LFA) or distributed (LA)
• Federation Peering Point (FPP)
– Able to announce BE metadata
• The Metadata Service (MDS)
– Publishing interface (to FPPs)
– Querying interface (to BEs)
The eduGAIN Model
Metadata
Query
Metadata
Publish
Connect. Communicate. Collaborate
MDS
R-FPP
R-BE
AA
Interaction
Resource(s)
Metadata
Publish
H-FPP
AA Interaction
H-BE
AA
Interaction
Id Repository(ies)
Component Identifiers
Connect. Communicate. Collaborate
• eduGAIN operations strongly depend on having
unique, structured and well-defined component
identifiers
• Based on URNs delegated by the eduGAIN
registry to the participating federation
• Identifiers establish the kind of component they
apply to by means of normalized prefixes
• Identifiers follow the hierarchy of the trust
establishing process
Some identifier examples
Connect. Communicate. Collaborate
• A typical MDS server identifier
urn:geant:edugain:component:mds:galaxian
|
COMMON PREFIX
|TYPE|CONFEDERATION|
• A typical FPP identifier
urn:geant:edugain:component:fpp:starfleet
|
COMMON PREFIX
|TYPE|FEDERATION|
• A typical BE identifier
urn:geant:edugain:component:be:starfleet:enterprise
|
COMMON PREFIX
|TYPE|FEDERATION| IDENT |
eduGAIN Trust Fabric
Connect. Communicate. Collaborate
• Based on a PKI
• Validation procedures include
– Normal certificate validation
• Trust path evaluation, signatures, revocation,…
– Peer identification
• Certificates hold the component identifier
• It must match the appropriate metadata
• Applicable to
– TLS connections between components
• Two-way validation is mandatory
– Verification of signed XML assertions
eduGAIN CA Hierarchy
Connect. Communicate. Collaborate
eduGAINCA
eduGAINSCA
..
eduGAIN Fed1 CA
..
eduGAIN FedN CA
MDS server(s)
BE1
BE1
FPP FedA
...
...
BEN
BEN
...
FPP FedZ
LFA FedA
...
LFA FedZ
eduGAIN Operations
Connect. Communicate. Collaborate
• Defined in abstract terms, following the SOA paradigm
– Metadata Service (MDS)
– Authentication Service (AuthN)
– Attribute Exchange Service (Attr)
– Authorisation Service (AuthZ)
• Formally defined parameters for each operation
• Bindings defined for SAML 1.1 and part of SAML 2.0
– SAML 2.0 over REST for MDS
– SAML 1.1 over SOAP (and REST in WebSSO) for the others
– Plans for evolving these bindings as required
A general model for
eduGAIN interactions
Connect. Communicate. Collaborate
<samlp:Response......
<samlp:Request
RequestID=”e70c3e9e6…”
ResponseID=”092e50a08…”
IssueInstant=“2006-06…”>
InResponseTo=“e70c3e9e…”>
. . .
</samlp:Request>
</samlp:Response>
Requester
Resource
TLS Channel(s)
Responder
Id Repository
Metadata Service
Connect. Communicate. Collaborate
• Based on REST interfaces transporting SAML 2.0 metadata
• Metadata are published through POST operations
• Metadata are retrieved through GET operations
• URLs are built as
MDSBaseURL/FederationID/entityID?queryString
– Using component names
– The queryString transports data intended to locate
the appropriate home BE (Home Locators)
• Usually, coming from hints provided by the user
Mapping between SAML 2
and eduGAIN
–
EntitiesDescriptor  List <BEMetaData>
–
EntityDescriptor  BEMetaData:
Connect. Communicate. Collaborate
• componentID
• contactURL
• List <IDPInterface>
– componentID
– contactURL
– List <EGAttribute>
• List <AAInterface>
– componentID
– contactURL
– List <EGAttribute>
• List <HLPatterns>
– hlType (eg. homeDomain, urn, authenticationMethod)
– matchingAlgorithm (eg. prefix, postfix, exactMatch)
– value
General eduGAIN Operation
Mapping
Connect. Communicate. Collaborate
• Current version is based on SAML 1.1
– Profiling the standard to fit abstract parameters
– Component identifiers play their role again
• A SAML 2.0 implementation will be available along the
lifetime of the project
– The abstract service specification protects components
and applications from these changes
• Authentication assertions and attribute exchange
mechanisms are designed to be Shibboleth 1.3 compatible
– And Shibboleth 2 in the future
eduGAIN API Structure
Connect. Communicate. Collaborate
• The eduGAIN APIs are the common libraries for all
eduGAIN components
– Direct implementation of the eduGAIN service definition
– And also available to local requesters and responders
• Building blocks:
– eduGAINBase: Adapt the abstract service definition plus
specific profile-based access points
– eduGAINMetaQuery: Queries to the Metadata Service
– eduGAINMetaPub: Publication at the Metadata Service
– eduGAINVal: Validation procedures
A Layered Model for
Implementation
Component logic
eduGAINBase Profile Access
eduGAINBase + eduGAINVal + eduGAINMeta
SAML library
SOAP/TLS/XMLSig libraries
Connect. Communicate. Collaborate
eduGAIN Profiles
Connect. Communicate. Collaborate
• Define the precise exchange of messages and the
processing rules for these messages in particular use
cases
• Two profiles defined so far
– Web SSO (Shibboleth compatible)
– Automated client (no human interaction)
• Others envisaged
– Extended Web SSO (allowing the send of POST data)
– Non-web applications (based on Web SSO)
– eduGAIN usage from roaming clients (DAMe)
eduGAIN WebSSO
Connect. Communicate. Collaborate
• Intended to connect existing Web-based AAIs
– And to experiment with the whole eduGAIN model
• Based on HTTP redirects
– Making use of the user’s browser
– Fully compatible with Shibboleth 1.3
• The R-BE redirects the user’s browser to the H-BE
– Parameters go in the URL using a GET method
• The H-BE makes the user’s browser send a SAML
response
– By means of a POST operation back to the R-BE
Web SSO in action
R-BE
302 H-BE
GET
H-BE
FORM +
JavaScript +
SAML
GET/POST
User’s Browser
POST (SAML)
Connect. Communicate. Collaborate
Implementing WebSSO
through eduGAINBase
Connect. Communicate. Collaborate
• Two separate classes to provide access to the eduGAIN
abstract model
– Translating AuthN requests and responses into
WebSSO messages
• Two adaptor interfaces to connect local federations to
eduGAIN
– Translating internal requests and responses into their
eduGAIN counterparts
• Two components (servlets) implementing the BEs
– Fully configurable through servlet deployment
– A sample for other possible implementations of BEs
WebSSO
Web
SSO
Implementation Details
Connect. Communicate. Collaborate
Connect. Communicate. Collaborate
DAMe
Deploying Authorization
Mechanisms for Federated
Services in eduroam (DAMe)
•
Connect. Communicate. Collaborate
DAME is a project that builds upon previous TERENA, Internet2, and
University of Murcia work:
– eduroam, a result of TERENA Mobility Task Force, which defines an
inter-NREN roaming architecture based on AAA servers (RADIUS) and
the 802.1X standard,
– Shibboleth, a widely deployed federation mechanism.
– eduGAIN, the AAI of GN2
– NAS-SAML, a network access control approach for AAA environments,
developed by the University of Murcia (Spain), based on the SAML
(Security Assertion Markup Language) and the XACML (eXtensible
Access Control Markup Language) standards.
First goal: Extension of eduroam
using NAS-SAML
Connect. Communicate. Collaborate
Policy Decision Point
Source Attribute Authority
XACML
Supplicant
Authenticator
(AP or switch)
RADIUS server
University A
RADIUS server
User
DB
User
DB
University B
Gast
piet@university_b.nl
SURFnet
•
User mobility controlled by
assertions and policies expressed
in SAML and XACML
Signaling
Central RADIUS
Proxy server
data
SAML
Second goal: Use of eduGAIN as
authn and authz backend
•
Connect. Communicate. Collaborate
Link between the AAA servers (now acting as Service Providers) and the AAI
of eduGAIN or Shibboleth.
XACML
Policies
Policy Decision
Point
(SAML)
Authentication Statement
Attribute Statements
Access point
Shibboleth
Federation
Network Access Service
(RADIUS/DIAMETER
Acting as Service Provider)
Identity Provider
(Shibboleth)
Third goal: universal single
signon
Connect. Communicate. Collaborate
•
Users will be authenticated once, during the network access control phase
•
The eduGAIN authentication would be bootstrapped from the NAS-SAML
•
New method for delivering authentication credentials and new security middleware
XACML
Policies
Policy Decision
Point
(SAML)
Authentication Statement
Attribute Statements
Identity Provider
(Shibboleth)
Shibboleth
Federation
(SAML)
Authentication Statement or
Artifact
Network Access Service
(RADIUS/DIAMETER)
(SAML)
Authentication Statement or
Artifact
Service Provider
Assertion Consumer
Target Resource
Additional SAML
Attributes
Connect. Communicate. Collaborate
Summary and conclusions