Non-Person Entities – Delegation, Proxy and WS02, API manager

Non-Person Entities

Wednesday 1I

Convener: Dan

Notes-taker(s): Susan David

Tags for the session - technology discussed/ideas considered:

Non-Person Entities, Authentication, Things, Ownership, API Management

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

What Non-Person Entities are there?

• Organizations
• Server
• System
• Applications

Had to create “non-people” people.

Ws02 – can set up webservices and subscribe to them.

API Manager:

• User Login – receives bearer token
• Application subscribes to WS –

Administrators don’t want to have non-person entities in the LDAP, so NPEs not in LDAP, and don’t get a login.

Want to tie application login to person ID that ties into datastore.

So if I authenticated to the API Manager, build JWT with identity information.

Goal: each non person entity to have their own Client ID and Person ID and store in JWT and pass along to web service – how do others deal with this?

Many API managers come with tools for managing client credentials of non-persons.

WSO2 – works better when it runs everything. WS02 can talk to multiple credential stores.

Covisent: just set up a series of APIs for managing non-person identities. Handles authentication of things, how to exchange authorizations. Seeing things on the outside/things on the nside.

Are there proxy/delegation solutions .

“If a product is good at doing something – let it”

IT needs to stamp out the impulse to customize/build their own. If you want more modularity/reuse – incentivize it.

APIs force reuse - (Doucmentation makes APIs reusable)

Okana (used to be SOA software) created a function to translate WSDL, RAML, Swagger – last week.

Push to have application credentials stored in LDAP – single source of identity is the desire. Need standard schema for things.

Do JWT tokens get used to authenticate to other things? - yes – this has become common currency. (JSON Web Token)

Gateway can do any needed transformations.

Open Trust Taxonomy for OAuth (Mark Schwartz) – Oauth federations \\this could be used by API platforms.

Dynamic Onboarding: UMA might be something to look at:

UMA has two specs:

UMA Core: loosely couples AS and RS

UMA Resource Set Registration (RSR) : OIDC: OP and 3rd party attribute providers

• Federated authorization

If you have services, and want them to use your authorization service: this would be a way to do this.

SaaS: We can SSO onto SaaS, but what we really want is for them to provide Federated Authorization (Dynamic Entitlements) Imagine having the Scopes brought to every service within the Token. Scopes make entitlements reuseable (Scope grained access control, by taking federated authorization approach).

Are Scopes standardized? No – entirely unstandardized (causing a fight). Now they are just keywords. UMA tried to standardize them by making them Http verbs – fell apart. However, can make them be URLs – User URL has to be resolvable. AS has to be able to grab it, so that the user can set policy.

Scopes: (A,B,C..) all in RSC. UMA: A,B,C will be registered against resources (R1, R2, R3): Resources can be end points, information – think of it as nouns and verbs.