FHO Fachhochschule Ostschweiz

EduID Mobile AppUse-cases, Concepts, Implementation

@phish108 @htwblc

Part IUse Cases and Concepts

The “Cloud” from a Service Perspective

Clients

@phish108 @htwblc

The “Cloud” from a Device Perspective

Roaming Profiles

@phish108 @htwblc

The “Cloud” from a User Perspective

Smart Environments

@phish108 @htwblc

Shifting from Feature Services to Smart Environments

Glahn (2013). What we mean when we talk about mobile services. SIG Mobile Whitepaper @phish108 @htwblc

Personalization requires Authorization

Seite 6

Authorization is about Trust

OrganizationTrusted

User &App StoreTrusted

Mobile DeviceService Federation

Untrusted

Personal Data

Internet

@phish108 @htwblc

1. OIDC for Responsive Web-Apps

2. AppAuth for tightly integrated native mobile apps

3. Token Agent Authorization for loosely coupled native apps

@phish108 @htwblc

3 Approaches

Approach 1: Responsive Web-Apps (OpenID Connect / OAuth2, SAML)

@phish108 @htwblc

Open ID Connect: 3 Flows to Authorizations

@phish108 @htwblc

1. Implicit flow• Get an authorization from an IDP for accessing a service with limited

session details2. Code flow

• Receive an authorization code for fetching confidential session detailsfrom the IDP

3. Hybrid flow• Get an authorization from an IDP for accessing a service with

confidential session details in one step

OpenID Connect (OIDC)

26.04.2017Corporate IT, FHNW 11

«A Simple Identity layer on top of OAuth 2.0»

From the website (http://openid.net):

− OIDC is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of «making simple things simple and complicated things possible». It’s uniquely easy for developers to integrate, compared to any preceding Identity protocol.

− OIDC allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.

SAML vs OIDC vs OAuth

26.04.2017Corporate IT, FHNW 12

Simply said: − SAML: single sign-on for enterprise users− OAuth: API authorization between applications− OIDC: single sign-on for consumers + API access

Token format:− SAML: XML− OIDC: JWT (JSON web token)

The whole story:«Unifying Authentication & Delegated API Access for Mobile, Web and the Desktop with OpenID Connect and OAuth2 by Dominick Baier»https://vimeo.com/113604459

GET /authorize?client_id=app1&scope=openid profile&redirect_uri=https://app.com/cb&response_type=id_token token&state=af0ifjsldkj &nonce=n-0S6_WzA2Mj

Implicit Flow

26.04.2017Corporate IT, FHNW 13

− One of multiple flows (processes) defined in the specification− Specifically designed for «untrusted clients» such as JavaScript apps− Key steps:

−Client sends the request to the Authorization Server. −Authorization Server authenticates the End-User, obtains consent, sends him/her back to the Client with an

ID Token and, if requested, an Access (Bearer) Token. −Client validates the tokens and retrieves the End-User's Subject Identifier. −Client uses the Access Token for calls to Backend Web Services

@phish108 @htwblc

Approach 2: Integrated Service Apps or Service-bound Apps

(AppAuth)

© 2017 SWITCH | 15

Startseite Untertitel

Unternehmenspräsentation

Christoph Graf, Rolf Bruggerswisseduid@switch.ch

SIG Mobile, 25.4.2017 @SWITCH

Use case of a “Service-bound Mobile App”

SWITCHdrive App

SWITCHdrive

Sync & share on Swiss serversKeep your data on your devices synchronized and share them with your contacts – on secure safe servers

Your benefits• Data in Switzerland• Fast network connection to SWITCH• Simple user activation

Customers• Universities• Hospitals• Other institutions

Services• SWITCHdrive- Serverfarm, based on

ownCloud• High dissemination in academic

Switzerland (>80% of universities)

SWITCHdrive App –The official mobile clientof the SWITCHdrive service

• SWITCH-branded, based on owncloud app• Preconfigured with fixed endpoints for SWITCHdrive• Feature set in line with SWITCHdrive capabilities• Support limited to this app

Usage scenario description

• Controlling the user experience end-to-end• Service branding opportunity (CI/CD)• Needs to maintain an app

(development/adaptation/preconfiguration/testing, mobile martketplaces, etc.)

• One single app to document and support• No re-use opportunity of potentially compatible app

Service operator perspective

• Opportunity to develop, adapt, brand, preconfigure or support app exclusively for specific services as a contractor to service operator

• (Probably) no opportunity to offer alternatives to users bypassing service operator

• Uses standard authentication mechanisms (AppAuth, OAuth2, OIDC): availability of libraries, development and testing tools, tutorials.

App developer perspective

www.switch.ch/30years

SWITCH – an integral part of the Swiss academic community since 1987.

@phish108 @htwblc

Approach 3: EduID Mobile App(Token-agent assertions)

• Multi-LMS learning app• API dependent, not service dependent• No separate backend service• Entering and managing authorizations cumbersome

• Major UX barrier• Specialized solution for some didactics

@phish108 @htwblc

The Story of Mobler

@phish108 @htwblc

How relevant are these cases for your institution?

@phish108 @htwblc

Part IIEduID Mobile App Architecture

@phish108 @htwblc

EduID Mobile App Reference Architecture

1

234

5

• Focus on business logic• Completely external SSO• Federation independence• Loose bounds with specific services and instances• Independence of specific authorization mechanics

• Multi factor authorization• Service-level authorization

• Customers binding@phish108 @htwblc

Benefits for Developers

• Continuous but flexible authorization and access control• Apps will not see forbidden service endpoints• Apps will not know authorization endpoints• Easier adoption of apps

• No immediate need for app customizations

@phish108 @htwblc

Benefits for Organizations

• One stop authorization and identity management• No need to enter URLs in apps. • No need to enter passwords all the time• Transparent and explicit authorization of services

@phish108 @htwblc

Benefits for Actors

Requirements• Minimum Changes compared to OpenID Connect implementations• No Interference with existing OpenID Connect and AppAuth• Only standardized concepts (RFC-level)

@phish108 @htwblc

Implementation Requirements for Service Providers

Solution • Variation of OAuth2/OpenID Connect Code Flow• Trust-agent initiates the code request phase, directly

• No separate authorization step• All request parameters are forwarded to the OAuth2 endpoints• Service extends code request with the required OAuth2 scope

@phish108 @htwblc

Implementation Requirements for Service Providers

@phish108 @htwblc

PHP-

Code

from

the

Moo

dle

Impl

emen

tatio

n

if (array_key_exists("id", $_GET)) {

// Step 1: Code-flow, Hybrid-Flow

// normal use when the user comes via the login page

// triggers the authorization request

$callback->handleAuthorization();

}

elseif (array_key_exists("state", $_GET)) {

// Step 2: Code-flow, Hybrid-Flow

// response from the authorization endpoint

$callback->authorizeUser();

}

elseif (array_key_exists("assertion", $_GET)) {

// EduID Extension: rfc7521 forwarding

$callback->authorizeAssertion();

}

else {

// bad request or OAuth2 error

http_response_code(403);

exit;

}

public function authorizeAssertion() {

// rfc7521 forwarding: extend the incoming assertion parameters

$param = array_merge($_GET, ["scope"=> "openid profile email"]);

// Fetch the access-token and user–information

// - this is the same call as in step 2 of the Code Flow

$res = $this->callTokenEndpoint($param);

if (!$this->handleToken($res)) {

http_response_code(403);

}

}

@phish108 @htwblc

PHP-

Code

from

the

Moo

dle

Impl

emen

tatio

n

Reduction of Business Logic • Authorization request via mobile-OS instead of self-authorization

• Self-identification• Service or service-capability demands• Single or multi-endpoint handling

• Endpoint and token management (as usual)

@phish108 @htwblc

Implementation Requirements for App Developers

App Authorization for Service

Further reading http://htw.ac/eduid-mobile

@htwblchttp://htw.ac/blc-blog

FHO Fachhochschule Ostschweiz