1. University of Murcia Gabriel López

2.  Network authentication in eduroam and SSO token distribution ◦ RADIUS hierarchy ◦ Token based on SAML  Network authorization based on end user attributes ◦ Based on eduGAIN BEs ◦ XACML authorization policies  Web authN and authZ profile  Beside: ◦ Integrated with Shibboleth and PAPI idPs ◦ Support for LoA (Level of Assurance) ◦ RadSec deployment in progress

3.  New services for SSO  Based on the SSO token provided by DAMe  Provide APIs for BEs:  Token generation  Token validation  Authorization  Unified SSO token  perfsonar, DAMe, etc  Provide optional authorization for VoIP services based on end user attributes  SIP protocol for testing

5.  Profile 1: The user has a valid SSO token ◦ From the end user network authentication (DAMe) ◦ New registration method required ◦ Token validation through BEs ◦ Extending registration method for authorization  Profile 2: The end user does not have a valid SSO token ◦ Receives a new SSO token for further authentications (VoIP, Web, etc…) ◦ Who does the end user authentication?  VoIP Registrar vs idP ◦ Who does the token generation? BEs vs idP

6.  Profile 2: SSO token generation delegated to the BEs (DAMe-based)  Profile 2.1 Traditional authentication in the registrar server (HTTP-Digest)  Authentication in the registrar server  Profile 2.2 Authentication based on HTTP (HTTP-redirect)  Authentication in the idP  Profile 2.3 in-line/native authentication (new method)  Authentication in the idP ◦

8.  Extension of SIP messages: ◦ Register (token) ◦ New authentication method  Extension of SIP proxies: ◦ Token validation  BEs ◦ Authorization based on end user and environment attributes  BEs  Authorization process (attributes recovery and PDP requests are transparent for proxies )

10.  Extension of SIP messages: ◦ OK 200 (token) ◦ Classic authentication  Extension of SIP proxies: ◦ Token generation request  BEs ◦ Authorization based on end user and environment attributes  BEs

12.  Extension of SIP messages: ◦ REGISTER (artifact) ◦ OK 200 (token) ◦ HTTP redirection authN  Extension of SIP proxies: ◦ Token generation request  BEs ◦ Authorization based on end user and environment attributes  BEs

14.  Extension of SIP messages: ◦ OK 200 (token) ◦ Register includes end user creds (protected channel needed)  Extension of SIP proxies: ◦ Token generation request  BEs ◦ Authorization based on end user and environment attributes  BEs

15.  AuthnRequest(SSOToken): Boolean ◦ SSOToken validation (profile 1)  Validity Period, signature (PKC chain, trust anchors, etc)  AuthnQuery(user): SSOToken ◦ Requests authentication statement from idP (profile 2.1) ◦ Generates SSO token  AuthnRequest(artifact): SSOToken ◦ AuthN statement recovery from idP (profile 2.2) ◦ SSO token generation  AuthnRequest(creds): SSOToken ◦ Sends authentication requests (application specific to idP) (profile 2.3) ◦ SSO token generation

16.  AuthzRequest(SSOToken): Boolean (+obligations) ◦ Recover end user attributes from home domain  Through eduGAIN BEs  Directly from the AttributeProvider ◦ Request an Authorization Decision  To the local PDP  Based on End User id, End User attributes, resource, action, other info (date/time, network load, etc.)

17.  SIP allows the extension of standard messages ◦ Extension Service Instruction  Authentication methods have already been proposed in other works  BE-API valid for other services?  Compliant with other SAML/SIP proposals (Tschofenig)  Security of the token ◦ alice  R-SIP Registrar ◦ SIP/SSL, IPSec, token encryption

18.  backup