onedevatlasBeta
Browse the atlas
AllCAPUI5ABAPBTP
SampleSampletypeA worked example you read or clone. Evidence: it demonstrates, it never provides.See every one →What this type is →independently maintainedindependently maintainedoriginPublished by one person or a small company outside SAP. Says nothing about quality; the readings say that.See every one →Reference

auth-samples

Two CAP services and a UI over them, set up so role and instance restrictions can be tried out against three mock users instead of a real identity provider.

SalesOrderService requires an authenticated user, and its SalesOrders and SalesOrderItems entities each grant READ to Viewer, READ and WRITE to Sales and READ to Admin, with where: 'company = $user.company' on the Viewer and Sales grants alone, so those two see only the rows of their own company while Admin reads every one. The Products entity carries the same three grants and no instance restriction. The three users the README sends a reader to sit in salesorders/.cdsrc.json under the mock strategy, each with one role and a Company and a Region attribute; company is the only attribute any rule reads, and the three users differ in it, so a restriction can be seen to bite by logging in as someone else. The products project is consumed by the salesorders one as an imported OData service, over basic authentication against a fixed user locally and through a products-srv destination in production. What a local run uses is the mock strategy; what a deployment binds is in the project's own mta.yaml, which declares an xsuaa instance with its xs-security.json, a destination instance and an HDI container.

GitHub0 ★

Facts

Last push

Where it sits

Lives in
CAP
Demonstrates
AuthenticationCAPAuthenticationcapabilityEstablishing who is calling: validating credentials or tokens, resolving the user, and making that identity available to the application. [Authorization](capability:authorization) decides what that identity may do; [identity provisioning](capability:identity-provisioning) manages its lifecycle across systems.AuthorizationCAPAuthorizationcapabilityDeciding who may read or change what, at service, entity and instance level — role checks, forwarded user context, and restrictions evaluated as query filters rather than after the fact.Service integrationCAPService integrationcapabilityUsing a service that runs somewhere else as if it were one of your own: its API imported into the model, a proxy that turns a local query into the remote protocol, and a mock that stands in for it on a laptop. Distinct from [destinations](capability:destinations), which is how the address and the credentials are found, and from [replication](capability:replication), which is holding the data locally.
Flavors
Node.jsfrom its runtime
Runs
Cloud Foundry
Requires
SAP Authorization and Trust Management serviceSAP Authorization and Trust Management serviceartifactThe project declares its uaa binding as kind xsuaa, and the MTA deploys an xsuaa instance from the project's own xs-security.json: outside a local run, that instance is where the roles the restrict rules name live.SAP Destination serviceSAP Destination serviceartifactIn production the imported products service is reached by the name of a destination rather than an address, and the MTA binds a destination instance on the lite plan to the service module.

Who is behind it

Mio YasutakeMio YasutakePersonMaintains this
In the atlas: maintains 47, contributes to 47, wrote 10@miyasutamaintainer

Before choosing this

Signals

LicenceNo licenseNeither the package manifest nor the repository tree declares a licence

Without a licence the default is all rights reserved. Ask the maintainer, or check for terms stated elsewhere, before depending on it.

What it declares

Every artifact

Type
Sample
Origin
Independently maintained
Use as
A reference
Runtime
Node.js
Runs on
Cloud Foundry

As a sample

Form
does not say

Connections5

Download
auth-samples connectionsauth-samplesPROVIDES→ demonstrates3demonstrates authoredAuthenticationdemonstrates authoredAuthorizationdemonstrates authoredService integrationNEEDS→ needs2needs declared The project declares its uaa binding as kind xsuaa, and the MTA deploys an xsuaa instance from the project's own xs-security.json: outside a local run, that instance is where the roles the restrict rules name live. miyasuta/auth-samples — salesorders/package.json: https://raw.githubusercontent.com/miyasuta/auth-samples/master/salesorders/package.json miyasuta/auth-samples — salesorders/mta.yaml: https://raw.githubusercontent.com/miyasuta/auth-samples/master/salesorders/mta.yamlSAP Authorization and Trust Managementserviceneeds declared In production the imported products service is reached by the name of a destination rather than an address, and the MTA binds a destination instance on the lite plan to the service module. miyasuta/auth-samples — salesorders/package.json: https://raw.githubusercontent.com/miyasuta/auth-samples/master/salesorders/package.json miyasuta/auth-samples — salesorders/mta.yaml: https://raw.githubusercontent.com/miyasuta/auth-samples/master/salesorders/mta.yamlSAP Destination service

README

quoted from miyasuta/auth-samples, read
miyasuta/auth-samples/README.mdOn GitHub

auth-samples

UI + 2 CAP projects with authentication handling

excerpt, no licence read, read the rest, on GitHub

Details

Sources3
GitHub organisations and accountsdiscovered here, miyasutachecked
github.com/miyasuta/auth-samplestree, pushes, contributors, CIchecked
README.mdquoted, and what the entry declareschecked

Sources are graph entities: the same page may back several entries, and an unreachable source flags every row that rests on it.

Compatibility and provenance
runtimesnode
deploymentCloud Foundry
discovered viaGitHub organisations and accounts · miyasuta
first seen in the atlas
ecosystem and domaincap, security-and-compliance
History in the atlas1
  1. First seen.
For your agent
Ref
artifact:miyasuta-auth-samples
JSON
/artifacts/miyasuta-auth-samples.json
MCP
Connecting an agent