Overview about OAuth 2.0 Support • What is OAuth 2.0? – OAuth stands for "Open Authorization" and its a free and open protocol built on IETF standards, that aims to solve the problem of credentials proliferation all over the web. – OAuth 2.0 became very popular across social networks such as Facebook, Twitter and other websites like Google. However, it is becoming a de-facto standard for security in any software architecture that is API-based. Therefore its relevance for API Platform. • The Valet Key Metaphor – OAuth supports this "Delegated Authentication" between web apps using a security token called access token. Eran Hammer-Lahav, a spec author for OAuth compares the access token to a valet key: Its an access token with limited rights that can operate the vehicle - but don't grant full access to the car - such as to the glove compartment. Introduction to OAuth 2.0 and its usage in API-based Architectures
Overview about OAuth 2.0 Support • Meeting the main Personas – Client: Also called "The App" and it runs either on a mobile device or an web app. It makes requests to a resource server on behalf of a resource owner. – Resource Owner: Also called "End User". Person capable of granting access to a protected resource. – Resource Server: Service that hosts the protected resource, like the API Gateway. – Authorization Server: Service capable of issuing access tokens. Introduction to OAuth 2.0 and its usage in API-based Architectures Client Resource Owner Authorization Server Resource Server Authorization Request Authorization Grant Authorization Grant Access Token Access Token Protected Resource
Overview about OAuth 2.0 Support • APIPCS supports the two most common scenarios related to OAuth 2.0: Support Available in APIPCS for OAuth 2.0 API Consumption: In this scenario, the API Gateway acts as a client of the API that is protected by OAuth 2.0. Before transmitting messages, it will set up an valid access token. API Exposure: In this scenario, the API Gateway will expose an API to be consumed by clients. Any client that invoke these APIs will have to provide an access token within the request. Once the request arrive in the API Gateway, it will validate the access token and decide if the request will be authorized or not.
Overview about OAuth 2.0 Support Support Available in APIPCS for OAuth 2.0 API Consumption Resource Owner Authorization Server Client API Gateway Backend Service Create application, specify grant types and operations Define protected resources, as well as audience and scope Forwards an request to the exposed API Authorization: Bearer <Access Token> Obtain access token based on the configured grant type (i.e.: Client Credentials or Resource Owner)
Overview about OAuth 2.0 Support Support Available in APIPCS for OAuth 2.0 API Exposure Resource Owner Authorization Server Client API Gateway Backend Service Create application, specify grant types and operations Define protected resources, as well as audience and scope Obtain access token using the allowed grant types Authorization: Bearer <Access Token> Forwards an request to the exposed API
Overview about OAuth 2.0 Support • What is JWT? – JWT means "JSON Web Token" and it's a open standard (RFC 7519) that defines a compact and self-defined way for securely transmit information between parties. – It is transmitted in a JSON format, but its small enough to be efficiently transmitted using the HTTP protocol, as well as self-contained, meaning that it holds all the data. – Structure of a JWT Base64(Header) + "." + Base64(Payload) + "." + Signature Access Tokens: An Overview about the JWT Specification { "alg" : "HS256", "typ" : "JWT" } { "sub" : "riferrei", "iss" : "http://identity.oraclecloud.com/", "scope" : "urn:opc:idm:t.security.client" } RSASHA256 ( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret ) Header Payload Signature eyJhNiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E20RMHrHD + +
Invoking OAuth 2.0 Protected APIs • In order to invoke APIs that are protected by OAuth 2.0, you are gonna need the following component: – Service Accounts: Resource that defines the security credentials required to invoke a backend service. It supports Basic Auth and OAuth 2.0 - and can be used by multiple APIs or Services. Overview about Service Accounts • You can associate Service Accounts and APIs through the Service Request policy. Or if you are using a Service, through the Service definition page.
Invoking OAuth 2.0 Protected APIs Anatomy of an Service Account Specifies if the Service Account is going to create credentials for a backend that is using Basic Auth or OAuth 2.0. Changing this modifies the UI params.
Invoking OAuth 2.0 Protected APIs Anatomy of an Service Account URL from the Identity Provider where access tokens can be requested. If the backend service needs special scopes to work, set then here.
Invoking OAuth 2.0 Protected APIs Anatomy of an Service Account Specifies the "grant_type" parameter of the access token request. Use these fields to configure how the gateway is going to authenticate in the identity server. Set how the access token will be sent to the backend in the request. Most cases is by header.
Invoking OAuth 2.0 Protected APIs • Keep in mind that Service Accounts can only be managed by users that are part of a group called "ServiceManagers". If an user doesn't have that group, then the Service Accounts will be inaccessible for him/her. Anatomy of an Service Account
Exposing OAuth 2.0 Protected APIs • In order to implement authorization based on OAuth 2.0 in your APIs using APIPCS, you're gonna need two components: – OAuth 2.0 Policy: Implemented as a policy in the API level, within the request pipeline. – Security Profile: Implemented in the Gateway level, to support the OAuth 2.0 policy. Overview about the OAuth 2.0 Policy and the Security Profile • The role of these components is helping to perform delegated authorization of the requests using access tokens, as well as scope-based authorization.
Exposing OAuth 2.0 Protected APIs Anatomy of the OAuth 2.0 Policy The enforcement options listed in the UI of the OAuth 2.0 policy are available only if you need to implement scope-based authorization. That means that if there are no scopes to enforce after the access token is deemed as valid, then there is no reason to configure this functionality. In this case, set the option to "Any". If the options "At Least One" or "HTTP Method Restricted" are selected, then the policy validates if at least one scope in present in the access token.
Exposing OAuth 2.0 Protected APIs Anatomy of the Gateway Security Profile Configuration Public Key used to authenticate the identity provider, which means check if the access token signing was based on the Private Key's counterpart. Set the Public Key format. If the access token is not sent over a secure channel, set this to NONE. Otherwise it'll fail. Add an extra step to check if the algorithm (JWA) used to sign the access token, is the same configured here.
Exposing OAuth 2.0 Protected APIs Anatomy of the Gateway Security Profile Configuration Use to specify the field name that the identity provider uses for the scope. Sometimes required since the scope claim name is not standardized. Since claims are not standard, use to specify which ones must be present in the access token. Usually, never needs to be set. Specifies the type of identity provider. Possible values are DEFAULT (applies for most of the cases) and FORGEROCK_ OPENAM.
Exposing OAuth 2.0 Protected APIs Anatomy of the Gateway Security Profile Configuration Use this field to set the header entry that will hold an IDToken. This setting only make sense if the value of the Name is set to FORGEROCK_OPENAM. Most identity providers don't rely on IDTokens explicitly. In future releases, there will be only two options to set in the Name field to differentiate the providers that support IDTokens from the ones whose not.
Exposing OAuth 2.0 Protected APIs Anatomy of the Gateway Security Profile Configuration List of audience values - separated by a pipe - that must be present in the access token. Used only if the AudienceRestrictionFromConfig is true. Use this field to determine if the audience is enforced by the values set on the Audience field or, if it will be enforced by the URL of the gateway. Set the value of the identifier from the identity provider that will issue the access tokens.
Exposing OAuth 2.0 Protected APIs Anatomy of the Gateway Security Profile Configuration • There is a special case when the AudienceRestrictionFromConfig field is set to false. If that happens, you can configure if the audience will be verified against the exact match of the gateway URL or if a partial match is enough. • If the field AudienceRestrictionEntireUrlMatch is set to true then the whole URL from the gateway must match with an audience from the access token. Otherwise, a simple match against the path info would be enough. – Example: http://apics.oracle.com:8001/api/check versus simply /api/check
What is Coming On 18.1.X? • Two ways to Install the Security Profile: – The current REST call will create the profile with the file name as OAuthProfile.xml, and it will install under the gateway at "apics/profiles/oauth". No manual restarts will be required anymore. – Also, you'll be able to physically put the profile at the same location under the gateway, but an manual restart will be required. • Audience Restriction at each API Level – Currently; regardless of what is set in the AudienceRestrictionFromConfig field, the audience verification is same for all APIs. Different approaches requires more gateways. – 18.1.1 will bring the ability to verify audience per API. It will first verify in a global audience list - and if no element is found there - it will verify per API endpoint URL. Improvements in the OAuth 2.0 Security Profile
What is Coming On 18.1.X? <AudienceRestrictionFromConfig>true</AudienceRestrictionFromConfig> <Audience>OAuthTestApp</Audience> <AudienceRestrictionsForAPIEndpointURL> <endpointApiURL name="/invoice"> <AllowedAudience>http://den01:8001/test|myPlan|SilverPlan</AllowedAudience> </endpointApiURL> <endpointApiURL name="/quotes"> <AllowedAudience>http://den01:8001/quotes|myPlan|GoldPlan</AllowedAudience> </endpointApiURL> <endpointApiURL name="/test"> <AllowedAudience>http://den01.us.oracle.com:8001/test|SilverPlan</AllowedAudience> </endpointApiURL> </AudienceRestrictionsForAPIEndpointURL> Sample Configuration using per API Endpoint URL Audience Restriction
What is Coming On 18.1.X? • A new field called AudienceRestrictionUsingLBR is being added to profile, as an enhancement of the audience verification. If that field is set to true, then the verification will occur against the Load Balancer URL instead of against an specific gateway. • This option will be particularly useful for production environments where there are multiple gateways being used and all request pass-through an Load Balancer. • Note that the field AudienceRestrictionEntireUrlMatch can also be used in conjunction with this new option. – Example: http://lbrHost:lbrPort/api/check versus simply /api/check Improvements in the OAuth 2.0 Security Profile
What is Coming On 18.1.X? • Since the scope claim name is not standardized, different IDP's can create scope claim name with different names. In order to address this issue, an element called "ScopeClaimName" will be defined in the security profile to override the default scope name. That will solve scenarios where some IDP uses "scp" to handle the scope. • Also, the values of the scope are expressed as a list of space-delimited, case sensitive strings in line with what is defined in: – https://tools.ietf.org/html/rfc6749#section-3.3 Federation with other JWT based Identity Providers
riferrei
ivargrimstad
nekomatu
irof
javiergs
tutinoko
hideg
little_rubyist
seike460
syumai
manfredsteyer
maaretp
pedronauck
palkan
paulrobertlloyd
tenderlove
tanoku
eitanlees
andyhume
danielanewman
jponch
bluesmoon
brad_frost
