Sie sind auf Seite 1von 39

PINGIDENTITY.

COM
OAUTH WITH
PINGFEDERATE
Ping Identity Education

2
GENERAL FLOW
IDTel’s
Authorization
1. Client redirects user to the 1. Client ID
+ scope
Server
authorization server AuthZ
(Tunes Partner website to ID requested Endpoint
Tel’s PingFederate).
Token
2. User Endpoint
2. User authenticates, then
authorizes the request. Authorization
(Yes, Tunes Partner can charge
me $10)
3.
Authorization 4. Auth Code + client secret
3. PingFederate redirects user Code in sent to PF
back to web app with an redirect 5. Access token (/refresh
authorization code token) sent to client

4. Client sends authorization


code to PingFederate with
client secret, requesting an
access token 1

5. PingFederate returns the 3


Resource Owner - Client
access token (/refresh token) .
User (Tunes Partner)

Copyright © 2015 Ping Identity Corp. All rights reserved.


3
AUTHORIZATION SERVER RESPONSIBILITIES

§ Maintain scope
list
§ Maintain client
list
§ Issue
authorization
codes
§ Issue access and
refresh tokens
§ Possibly,
authenticate user
Copyright © 2015 Ping Identity Corp. All rights reserved.4
SCOPES ARE DEFINED BY AUTHORIZATION
SERVER
§ A client app cannot request something not on the list
§ Can request any combination of the list

User Permission Description

publish_actions Enables your app to post content, comments, and likes to a


user's stream and to the streams of the user's friends

user_location Provides access to the user's current city as the location


property
ads_management Provides the ability to manage ads and call the Facebook
Ads API on behalf of a user.

Copyright © 2015 Ping Identity Corp. All rights reserved. 5


GENERAL AUTHORIZATION CODE
CONFIGURATION

• Timeout should be minimized


• One time code usage
• Entropy: Size

Copyright © 2015 Ping Identity Corp. All rights reserved. 6


GENERAL REFRESH TOKEN & PERSISTENT
GRANT

§ Idea:
– Short-lived tokens between the client and the RS
– Long-lived tokens between the client and the AS
§ Refresh an expired access token without involving user authorization
§ Refresh tokens can be revoked; access tokens can’t
Copyright © 2015 Ping Identity Corp. All rights reserved. 7
GENERAL CLIENT CONFIGURATION

§ A client will
initially send a
request
– “I’m TunesPartner
and want to
charge $5”

§ PingFederate will
check its client
list
Copyright © 2015 Ping Identity Corp. All rights reserved.8
GENERAL CLIENT CONFIGURATION
§ Client ID
§ Client secret
§ Redirect URI:
– Callback URL
§ Grant type

Copyright © 2015 Ping Identity Corp. All rights reserved.9


GRANT TYPE FLOWS
• All clients must have an access token to gain access to
protected resources.
• Grant Types
– Authorization Code
– Implicit
– Resource Owner Password Credentials
– Client Credentials
– Refresh Token

Copyright © 2015 Ping Identity Corp. All rights reserved. 10


AUTHORIZATION CODE GRANT CLIENT

§ Client secret:
– optional
§ Refresh token:
– allowed
§ Redirect URI:
– yes

Copyright © 2015 Ping Identity Corp. All rights reserved. 11


IMPLICIT GRANT CLIENT

§ Client secret:
– no
§ Refresh token:
– no
§ Redirect URI:
– yes

Copyright © 2015 Ping Identity Corp. All rights reserved. 12


ROPC GRANT CLIENT

§ Client secret:
– yes
§ Refresh token:
– allowed
§ Redirect URI:
– no
› (no browser!)

Copyright © 2015 Ping Identity Corp. All rights reserved. 13


CLIENT CREDENTIALS GRANT CLIENT

§ Client secret:
– yes
§ Refresh token:
– no
§ Redirect URI:
– no
› (no browser!)

Copyright © 2015 Ping Identity Corp. All rights reserved. 14


Resource Server
ACCESS TOKEN VALIDATION
CLIENT CONFIGURATION

15
ACCESS TOKEN VALIDATION GRANT CLIENT
① OAuth client
AuthZ
Endpoin application sends
t
the access token to
Token Resource Server
Endpoint

② RS validates
2. Access
Token incoming access
Validation token with
PingFederate
1. Access Token

3. Requested Resource or Affirmation


RS
Client

Copyright © 2015 Ping Identity Corp. All rights reserved. 16


ACCESS TOKEN VALIDATION CLIENT

§ Client secret:
– yes
§ Refresh token:
– no
§ Redirect URI:
– no
› (no browser!)

Copyright © 2015 Ping Identity Corp. All rights reserved. 17


SANITY CHECK! CLIENT GRANT TYPES
SUMMARY
Clients need to be pre-configured in the Authorization Server

Client Profile Grant Type Client Secret? Redirect URI?


Web Server App Authorization Code ✔ ✔

Browser-Based App Implicit ✖ ✔

Native Mobile App Resource Owner Password ✔ ✖


Credentials
Internal Server App Client credentials ✔ ✖
Resource Server Access Token Validation ✔ ✖

Copyright © 2015 Ping Identity Corp. All rights reserved. 18


NOTE: ENDPOINTS
§ AS Endpoints – hardcoded in PF AuthZ
– Authorization endpoint Endpoin
t
› Resource owner on the front channel
(browser redirect) Token
Endpoint
› pingfederate.idtel.com/as/authorization.oauth2
– Token endpoint
› Client on the back channel
› pingfederate.idtel.com/as/token.oauth2

§ Client Endpoint
– Redirection URI
› Front channel callback for resource owner (browser redirect)

Copyright © 2015 Ping Identity Corp. All rights reserved. 19


SUMMARY
§ PingFederate as authorization server
§ General configuration
– Gets authorization from user
– Defines scopes
– Defines clients
§ Issues and manages
– Access tokens
– Authorization codes
– Refresh tokens
TAKING A BREATH

eserved.21
MANAGING GRANTS

22
PINGFEDERATE – PERSISTENT GRANTS TABLE

§ SQL here: <pf-home>/pingfederate/server/default/conf/access-grant/sql-scripts

§ Single table
(pingfederate_access_grant):

Column Type
guid VARCHAR(32)
hashed_refresh_token VARCHAR(256)
unique_user_id VARCHAR(256)
scope VARCHAR(1024)
client_id VARCHAR(256)
grant_type VARCHAR(128)
context_qualifier VARCHAR(64)
issued TIMESTAMP
updated TIMESTAMP
expires TIMESTAMP
Copyright © 2015 Ping Identity Corp. All rights reserved. 23
USER MANAGEMENT OF PERSISTENT
GRANTS IN PINGFEDERATE

• https://<pfhost:port>/as/oauth_access_grants.ping
• Template:
<pf-home>/pingfederate/server/default/conf/template/oauth.access.grants.page.template.html

Copyright © 2015 Ping Identity Corp. All rights reserved. 24


CLIENT MANAGEMENT OF PERSISTENT
GRANTS IN PINGFEDERATE
§ Client Application can revoke refresh and access tokens
– E.g. application removed from a device and cleans up after itself

§ Client can only revoke tokens issued to it

Copyright © 2015 Ping Identity Corp. All rights reserved. 25


GRANT API
§ Ability for administrators to review and revoke grants without having to go into database base

– By Clients

– By Users

– Requires PCV For Authentication, same as the OAuth Client API

/pf-ws/rest

§ Get list of client grants:

– GET https://<pf-server:pf-runtime-port>/pf-ws/rest/oauth/clients/<clientID>/grants

– Note: Client database must be enabled

§ Get list of user grants:

– GET https://<pf-server:pf-runtime-port>/pf-ws/rest/oauth/users/<userID>/grants

§ Revoke grant for user:

– DELETE https://<pf-server:pf-runtime-port>/pf-ws/rest/oauth/users/<userID>/grants/<grantID>

Copyright © 2015 Ping Identity Corp. All rights reserved. 26


MAPPINGS

eserved.27
OAUTH – ADAPTERS
§ IDTel authorization server needs to authenticate the
user
– whose bank account is being charged?

§ Thus, PingFederate needs to have adapters


– (yes, those adapters)
– map adapters (/databases/directories) to the access token
– similar to mapping a SAML assertion

Copyright © 2015 Ping Identity Corp. All rights reserved.28


OAUTH ADAPTER MAPPINGS
§ PingFederate maps:
– USER_NAME
› A name to present the user on the authorization page
› “Bob, can Tunes Partner charge you?”

– USER_KEY
› An identifier for the user in general

Copyright © 2015 Ping Identity Corp. All rights reserved.29


OAUTH ADAPTER MAPPING

USER_KEY: Value for persistent grant


USER_NAME: Value presented to user on authorization page
Copyright © 2015 Ping Identity Corp. All rights reserved.30
OAUTH ACCESS TOKEN MAPPING
§ PingFederate will give out access tokens – these
will have attributes
§ Can define different access tokens for different
clients
– Tunes_partner – (account_to_charge=Alice)
– Travel_organization – (frequent_flier_number=15165)
§ These values need to come from somewhere

Copyright © 2015 Ping Identity Corp. All rights reserved.31


EACH CLIENT CAN HAVE A CUSTOMIZED
ACCESS TOKEN


Issue Validate
Token Token

App API

eserved.32
OAUTH ACCESS TOKEN MAPPING TO
CLIENT

Copyright © 2015 Ping Identity Corp. All rights reserved.33


OAUTH ACCESS TOKEN MAPPINGS
§ PingFederate needs:
– A name to present the user on the authorization page
› “Bob, can Tunes Partner charge you?”
› Mapped as USER_NAME
– An identifier for the user in general
› Mapped as USER_KEY
§ This is the initial adapter mapping

Copyright © 2015 Ping Identity Corp. All rights reserved.34


ACCESS TOKEN MAPPING

Note: That USER_KEY in the persistent grant database was


mapped from the adapter
Copyright © 2015 Ping Identity Corp. All rights reserved.35
ADVANCED: OAUTH SCOPE
AUTHENTICATION SELECTOR

Copyright © 2015 Ping Identity Corp. All rights reserved. 36


ORDER OF OPERATIONS
1. Client sends request for access token, e.g. a GET request ike:
client_id=tunespartner&response_type=code&redirect_uri=tu
nespartner.com/callback|url&scope=charge10

2. PingFederate checks client list and validity of request


3. PingFederate checks scope and grant type requested
4. PingFederate uses adapter for authentication
– maps USER_KEY and USER_NAME
5. PingFederate maps the access token

Copyright © 2015 Ping Identity Corp. All rights reserved.37


LAB
§ Configure PingFederate as an Authorization Server
§ Configure clients:
– Authorization code client
– Implicit Client
– Resource Owner Password Credential
– Resource Server Client
§ Configure OAuth Adapter Selector
– Delete scope requested: HTMLForm adapter
– Delete scope not requested: HTTPBasic adapter

Copyright © 2015 Ping Identity Corp. All rights reserved. 38


PINGIDENTITY.COM

Das könnte Ihnen auch gefallen