Date post: | 22-Jan-2018 |
Category: |
Technology |
Upload: | christian-glahn |
View: | 330 times |
Download: | 0 times |
Shifting from Feature Services to Smart Environments
Glahn (2013). What we mean when we talk about mobile services. SIG Mobile Whitepaper @phish108 @htwblc
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
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
© 2017 SWITCH | 15
Startseite Untertitel
Unternehmenspräsentation
Christoph Graf, Rolf [email protected]
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
• 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
• 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