Voip service in dame eduroam
Sponsored Links
This presentation is the property of its rightful owner.
1 / 21

VoIP service in DAMe/eduroam PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on
  • Presentation posted in: General

VoIP service in DAMe/eduroam. Gabriel López. University of Murcia. DAMe: current status. 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

Download Presentation

VoIP service in DAMe/eduroam

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


VoIPservice in DAMe/eduroam

Gabriel López

University of Murcia


DAMe: current status

  • 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


VoIPservice in DAMe

  • 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


VoIP target scenario


VoIP/DAMe profiles

  • 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


VoIP/DAMe profiles

  • 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


Profile 1: The user has a valid SSO token


Profile 1: The user has a valid SSO token

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


Profile 2.1 Traditional authentication in the registrar server


Profile 2.1 Traditional authentication in the registrar server

  • 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


Profile 2.2 Authentication based on HTTP


Profile 2.2 Authentication based on HTTP

  • 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


Profile 2.3 in-line/native authentication


Profile 2.3 in-line/native authentication

  • 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


VoIP/DAMe: BE-API

  • 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


VoIP/DAMe: BE-API

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


Conclusions

  • 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


  • backup


Network authenticationand SSO tokendistribution


Network authorizationfornetworkproperties


Web authN/authZprofile


  • Login