1 / 21

VoIP service in DAMe/eduroam

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

irma
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. VoIPservice in DAMe/eduroam Gabriel López University of Murcia

  2. 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

  3. 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

  4. VoIP target scenario

  5. 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

  6. 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

  7. Profile 1: The user has a valid SSO token

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

  9. Profile 2.1 Traditional authentication in the registrar server

  10. 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

  11. Profile 2.2 Authentication based on HTTP

  12. 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

  13. Profile 2.3 in-line/native authentication

  14. 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

  15. 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

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

  17. 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

  18. backup

  19. Network authenticationand SSO tokendistribution

  20. Network authorizationfornetworkproperties

  21. Web authN/authZprofile

More Related