Glossary of Terms

Definitions for some of the terms used by the platform API.

#

2FA: Acronym for two-factor authentication.

A

access token: See OAuth access token.
admin (group): In the context of an API Scope Group, an Admin is the top-level group member, and can perform any functions associated with the group. For more information, see What can a group Admin do?
Ajax: An abbreviation for Advanced JavaScript and XML—A term for a set of related web development techniques that can be used together to update parts of a webpage without reloading the entire page. For an example of how the platform works with Ajax, see File Upload with Ajax.
Akana API Gateway: See gateway.
alert: A type of Dashboard item designed to inform app or API administrators about an issue such as an SLA (Service Level Agreement) violation. Alerts are only applicable to APIs.
anonymous user: A user who is browsing the platform without logging in.
API: A key resource in the Akana API Platform. An API provides a business with a way of using the Internet to extend business capabilities to connect with new customers in new ways. In this context an API is a Web service exposed outside the enterprise, typically using RESTful design principles, and often with JSON content.
API access request: A specific type of Connection Request. An API access request governs the relationship between an app and an API for the life of the connection. When an app team member requests a connection to an API on behalf of the app, the API administrator is notified of the pending request and can respond accordingly. The administrator's action to either approve or deny the request changes the state of the connection.
API Administrator: One of the roles defined in the Akana API Platform is that of the API Admin. Each API must have at least one Admin, and can have more. The API Admin approves or rejects connection requests, moderates the API's Forum (Board), views and manages alerts and trouble tickets, and manages documents, policies, and other information associated with the API. The API Admin can also view performance and usage data for the entire API, and can invite others to be Admins for the same API. For more information, see Managing Groups on the Platform.; Note: API Administrator and API Admin are the same role.
API Owner: Responsible for adding an API. In a scenario where a basic platform user cannot add APIs, a user who is assigned the role of API Owner can add APIs. The user who creates the API becomes the first API Admin.
API Scope Group: A group directly associated with a specific version of a specific API, public or private, and created by an API admin for that API.; An API scope group is uniquely related to an API. There are two types: Independently Managed, which can exist separately from the API, and Not Independently Managed, which is automatically deleted if the API is deleted.; Each member has a group member role, as a Member, Leader, or Admin. Each group can have multiple Admins, Leaders, and Members.; Note: In the past, we used the term Private API Group. However, since the licenses feature was implemented, API visibility is affected by multiple factors. For this reason, the term was changed to API Scope Group. We also used the term API Context Group.
app: An app (application) is a piece of software that delivers specific capabilities to its users. In the context of the Akana API Platform, an app is a piece of software that consumes one or more APIs.
app team member: One of the roles defined in the Akana API Platform is that of the app team member. Each app must have at least one team member and can have more. An app team member initiates contract requests, such as API access requests, moderates the app's Forum (Board), and views and manages trouble tickets relating to the app. The app team member can also view performance and usage data for the app's API usage, and can invite others to be team members for the same app. All app team members have the same rights. For more information, see Managing Groups on the Platform.
AppID: When a user registers an app in the Akana API Platform, the app is assigned an AppID. The AppID is the unique identifier for the app within the platform. All API calls include the AppID.
archivable: A flag used for internal purposes to track whether a Board item can be deleted without impacting other functionality. If an item is archivable, it can be deleted. If it is not archivable, deleting it could potentially impact the user experience. For example, if a user has a group membership invitation, and the Board item is deleted, the inviter could change the invitation, and there would be no way for the user to see the update without the original Board item.; If administrators are writing purge functionality for board items, it's important to make sure that only Board items with the archivable flag set to true are purged.; You might see this value in an RSS feed response to some operations relating to the Board for a resource, or to a user's home feed; for example, GET /api/apis/{APIID}/board.
A record (in DNS entry): A DNS entry for a website address includes an A record that maps the hostname or CNAME to the IP address of the DNS entry.
Assertion: See SAML assertion.
Assertion Consumer Service (ACS) endpoint: In SAML, the endpoint where the service provider will receive SAML assertions from the identity provider.
asset: A component, or resource, that can be created, used, reused, and acted upon. The API platform includes many asset types, including APIs, apps, services, schemas, policies, tenants, legal agreements, API access contracts, and others. The platform's use of this term is per the OMG Reusable Asset Specification (RAS) (http://www.omg.org/spec/RAS/2.2/PDF). The specification is a set of guidelines and recommendations about the structure, content, and descriptions of reusable software assets.
Artifact Resolution Service (ARS): In SAML, a service that you must set up if you want to use the HTTP Artifact binding (supported for single sign-on SAML response messages). You can then use the service to retrieve the full message using the artifact. See HTTP Artifact.
AtmoAuthToken: A tenant-specific cookie. This is the platform's authorization token. The token is returned in the Set-Cookie response header. This cookie indicates the level of access allowed. It is valid only for 30 minutes and must be renewed at that time. It also includes other information, such as the APIs, apps, and groups the user is a member of. When any of this information changes, the token must be renewed.; Because the AtmoAuthToken includes a lot of information about the user, in some cases, the token is long, and could potentially cause requests to fail if the server has a limitation on HTTP header length. For this reason, container configuration properties include authTokenMaxLength. When the AtmoAuthToken would be greater than the max length, the platform creates a mini auth token, and saves the full auth token in the database.
AtmosphereApplicationSecurityPolicy: A policy used to identify (authenticate) an app that is attempting to consume an API, to determine whether or not the app is authorized to access the API. This policy type supports multiple mechanisms for the app to present its identity.
Authorization endpoint (OAuth): See OAuth authorization endpoint.
Authorization header: The Authorization request header contains the username and password. It's sent by the client, to authenticate the client with the server. A client includes this header in its request after receiving a 401 Authentication Required response from the server. The Authorization header includes the authorization scheme and the authorization value.
auto-connect: An API setting that allows a contract to be created automatically with the API when a new app is created. The auto-connect feature can be specified per environment and can also be limited to specific licenses.
avatar: Within the platform, an avatar is an image that can be associated with a resource such as an app, API, user, or group.

B

base path

In the context of an API, the base path is the part of the URL that is after the hostname and is the same for all operations in the API.

The base path always starts with a leading forward slash (/). If nothing is specified for the base path, it defaults to the leading forward slash. This is the host root.

For an example, see Base URL below.

Base URL

In the context of an API, the base URL is the combination of scheme, hostname, and base path on the root level of the API. For example, in the Swagger Petstore API, the full URL for the POST /pet operation, which adds a pet, is http://petstore.swagger.io/v2/pet. The base URL is http://petstore.swagger.io/v2. This is constructed from these three elements:

Scheme: HTTP
Host: petstore.swagger.io
Base path: /v2

Base URL (SAML)

In setting up the SAML identity provider in Policy Manager, the platform provides a specific URL to be used for instances where the Identity Provider, when encountering an error, returns the error response to the default Service Provider endpoint rather than just showing the error on the authentication page. PingFederate is an example of an Identity Provider that returns an error response in this way.

To construct the endpoint to be used for error responses, the platform needs to know the {protocol_scheme}://{host}:{port} of the container where the SAML Web SSO domain is initialized. This is the base URL.

Basic authentication (HTTP)

Basic authentication requires that users provide a valid user name and password to access content. All major browsers support this authentication method and it works across firewalls and proxy servers. The disadvantage of Basic authentication is that it transmits passwords across the network using weak encryption. You should use Basic authentication only when you know that the connection between the client and the server is secure.

bearer token

Used in OAuth, the bearer token is a security token with the property that any party in possession of the token (the bearer) can use it. Using a bearer token does not require proof of possession of cryptographic key material (proof-of-possession).

Board

See Forum. In versions of the platform before 8.3, Forums for resources were called Boards.

Board item

See Forum entry. In versions of the platform before 8.3, Forum entries were called Board items.

business

In the Akana API Platform, a business is an entity that owns and publishes one or more APIs.

Business Administrator

One of the roles defined in the Akana API Platform is that of the Business Administrator. A business can own one or more APIs and apps, and must have at least one Administrator. The Business Administrator automatically has administrator rights over all the APIs and apps owned by the business as well as all the users who are part of the business. For more information, see Managing Groups on the Platform.

C

cache

When an HTTP message is sent and a response received, the client has the capability of caching the response. The response must therefore define whether the response content should be cached or not, via the Cache-Control response header. In the Akana API Platform, responses should never be cached, so the value is no-cache.

captcha

A visual challenge/response test used to maintain login security and help protect against security breaches. The test is designed to ensure that there is in fact a human logging in, not an automated process trying to break the password security.

CA SiteMinder

CA SiteMinder® is a popular commercial access management product. The platform supports use of CA SiteMinder for login or for OAuth support.

CDN

Acronym for content delivery network or content distribution network; a distributed system for serving content over the internet.

CER file

A message generated by a certificate authority in response to a request for a digital identity certificate.

When uploading app credentials, the app developer can upload either a CER file or a CSR file.

D

Dashboard: The user's Dashboard, also called home page or feed, is the first page the user sees after logging in. The Dashboard includes information relating to apps and APIs the user is associated with. An individual user's Dashboard is an aggregation of all the board items (forum entries) from all the resources that the user is following. An individual user can modify the types of information that are displayed on his/her Dashboard. See also Dashboard entry.
Dashboard entry/item: An informational item that appears on a user's Dashboard. The entries on a specific user's Dashboard are Board items for resources the user is following. A Dashboard entry can be any of the following: Alert, API Access Request (Contract Request), Discussion, Group Membership Invitation, or Ticket.
developer: A developer of an app that will consume an API.
denial of service policy: A policy that defines conditions for protecting against, and/or dealing with, a Denial of Service attack.
deployment zone: If an API is hosted on the platform and using the proxy capability, the API owner can specify one or more deployment zones, such as a geographical area or a specific data center, that the endpoint will be proxied in. The GET /api/deploymentzones operation returns a list of valid deployment zones.; A deployment zone can include one or more containers in a cluster. Multiple deployment zones could be at the same location, or could be in different data centers.; One of the advantages of defining deployment zones is that you can then designate API implementation/environment combinations that are eligible to be hosted in a specific deployment zone. For example, you might have one deployment zone designated for live API traffic, and another designated for all other types of traffic, such as sandbox and testing. This allows you to ensure that production servers are not impacted by testing activity.; The deployment zone definition includes information about the geographical location. In the API portal user interface, deployment zones are displayed in a map view. Although the host address is set up, the deployment zone can include a DNS redirection. This allows you to choose not to expose the actual hostname. You could have a DNS redirection for each deployment zone.; Deployment zones are defined separately for each tenant.; For more information, refer to Deployment Zones on the Platform.
Descriptor (API): In the context of an API, the API descriptor includes information about the API description document used for the API, such as a Swagger 2.0 document or WSDL file. It might include information such as a URL or Dropbox ID.
discussion: In the Akana API Platform, an authorized user can create a discussion topic about a resource (app or API) on the resource's Board. A discussion is typically, but not necessarily, created by someone other than the owner or administrator of the resource. Discussion entries are not threaded; users comment on the original item rather than on the comments/replies to the original item. Users can, however, mark or unmark the discussion itself and/or one or more discussion comments.; Each discussion has a title and one or more comments. The visibility of a discussion is controlled by the visibility of the resource it's associated with; for example, a discussion about a Limited (Private) API can only be seen by administrators and API Scope Group members associated with that API.
discussion type: In an earlier version of the Akana API Platform, discussions were categorized in separate discussion types, such as Comment or Question. Discussion types are no longer in use. In certain cases, a DiscussionType parameter might still be returned in a response message; if so, it can be ignored.
DL: API Descriptor Language. Abbreviation used in the Community Manager developer portal user interface and underlying API for API descriptor language document.
Dropbox: The Dropbox is a temporary storage area for files uploaded to the platform, such as images and certain types of content such as API definition documents. The file is first uploaded to the Dropbox and assigned a unique ID; then, further steps are taken, depending on the nature of the file.
duration: The duration of a request or response message is expressed with the Duration data type in the format PnYnMnDTnHnMnS. For example, a message response time of P0Y0M0DT0H0M0.022S indicates 22 milliseconds. For an expanded definition of Duration, refer to Data Types.

E

Entity ID: In SAML, a unique identifier for an entity. A SAML entity can be a Service Provider or an Identity Provider.; As a service provider, you define the Entity ID. When setting up your account with the Identity Provider you must specify the Entity ID, which must be unique within the IdP so that the IdP can identify your Service Provider.; The Entity ID is used as the value of the {Issuer} element inside the SAML protocol message. In an authentication request, the {Issuer} element contains the Entity ID of the Service Provider; in the SAML response, it has the Entity ID of the Identity Provider.; From the perspective of the Service Provider, the Entity ID is analogous to the client_id in OAuth.
entity references: When an HTTP GET operation in the platform returns information in the form of an RSS channel, it very often includes entity references. Where an RSS item represents an object, the entity references include additional information about the object. For example, if the RSS channel returns information about an app version, the entity reference might include information about the app to which the app version belongs. All relevant relationships to the object returned in the RSS response are represented in the entity references.
enumeration (of users): The term user enumeration, user enum, or simply enum refers to a security vulnerability that allows an unauthorized user to compile a list of valid user accounts that are authorized to log in to an application. For example, if an unauthorized user can try to sign up with an existing email address, and the application returns a message that an account already exists for that email address, the application is giving away information.; The platform includes enhanced security settings that can be activated to help prevent enumeration of users.
environment: A state defined by a workflow that corresponds to a software lifecycle stage (for example, Dev, Test, QA, Production).; An Environment has its own representation, or data model, for an API. and the assets that support that API. A customer may have several Environments in which the same API exists. Each Environment serves a different purpose such as development, testing, staging, or finally serving the business (production). Environments are typically chained together in an order of use, reflecting the development lifecycle. For example, development is before testing. An API is created first in the development Environment, and then in the test Environment. Changes to an API are made in the development Environment before being made in the test Environment.
environment data: The Promotion Package holds the data that needs to be promoted from the source environment to the target environment. This includes the environment data: the portion of the Source environment's data model that needs to be promoted. The environment data is in a format that the Promotion Coordinator does not need to understand. Only the environment systems need to understand the environment data and how to process it.
epoch time: Epoch time, also called Unix time, is defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time; Thursday, 1 January 1970. In some cases, the developer platform uses this value in response messages, expressed in milliseconds.
export: A Site Admin or Business Admin can output all the information about one or more of certain resources, or an entire business, to an export file. The information can then be imported into another platform instance. Information is exported to a specially formulated ZIP file called a package file.; Full export is only available to a Site Admin or Business Admin. An API Admin can export an API.

F

favicon: A small icon, typically 16x16 pixels, associated with a website or a specific webpage.; Implementation varies, but typically the browser displays the favicon in the address bar, on the tab next to the page title, and next to the page's name in a list of bookmarks.
FDN: The Fully Distinguished Name of a platform member. This applies to federated members. To uniquely identify an item across federation members, the Relative Distinguished Name (RDN) is joined with the hosting federation member's name to create a Fully Distinguished Name (FDN).
federation: Two or more Akana API Platform tenants who have unified to create a community in which APIs can be shared by users of both tenants. This feature is no longer supported.; The systems that participate in a federation (federation members, tenants) share information without requiring duplication of that information in each member and without relinquishing control of the information. Developers who sign up as users of one federation member can access information from a second federation member directly, without the need for signup or authentication by the second member. A federation setup requires the establishment of a trust relationship between federation members.
FedmemberID: Unique ID for a specific tenant; for example, acmepaymentscorp, acmepaymentscorp. The FedmemberID is the last part of most IDs.
feed entry: See Dashboard entry.
follow: The concept of following a resource on the platform is similar to the same concept in Twitter. When a user chooses to follow a resource, notifications relating to that resource are posted to the user's Dashboard to keep the user informed. There is also a separate list of resources that the user is following. For example, if there are many APIs on the platform, and the user is only interested in two or three, the user can choose to follow those specific APIs. They are displayed in a separate list, APIs you are following, making them easier to find. The same principle applies to all resources that can be followed: apps, APIs, and groups.
follow request: A specific type of Connection Request used to establish a follow relationship between a user and a resource that can be followed. Currently, only apps, APIs, and groups can be followed.
forum: In the Akana API Platform, every resource, such as an app or API, has a Forum that displays all feed entries for the resource. Users with approved connections to the resource can post items to the resource's Forum according to privileges. For example, a member of a specific app team can post items to the Forum for that app. Users with approved connections also see relevant Forum entries in their personal home Feed.; A Forum is a way of sharing information and content in the platform. Forum types include: Alerts, Contract Requests, Discussions, Group Membership Requests, Reviews, Tickets.; Forum types and Forum entry types are essentially identical. The difference is in implementation; the Forum is viewed by the Business Admin or Site Admin in Forum view (Administration > Forum), and is an overall view of Forum entries from all boards on the platform.
Forum entry: An individual content contribution by a specific user, to one of the Forum types. A Forum entry can be an Alert, API Access Request (Contract Request), Discussion, Group Membership Invitation, or Ticket.; In versions of the platform before 8.3, Forum entries were called Board items.
forward proxy: In general, a forward proxy is a server that acts as an intermediary, generally between client requests and another server.; In the context of the API platform, if an API is using the platform as a proxy, calls from clients to the API are sent to the platform and, from there, redirected to the API live endpoint. The Community Manager developer portal includes a configuration setting (Administration > Site) that allows the Site Admin to limit forward proxy activity to one or more specified hosts.

G

gateway: An Akana API Gateway streamlines management, deployment, development, and operation of APIs, enhancing security and regulatory compliance through authentication, authorization, and audit capabilities. It provides central definition and management of security, routing, orchestration, mediation, auditing, threat protection, and other operational governance policies across multiple instances. The Gateway enables enterprises to standardize API and service delivery with high security, performance, and availability.
GraphQL: A query language for APIs, that allows clients to be very specific about the information they are requesting. For more information, see What is GraphQL? For general information about GraphQL, see https://graphql.org/ (external link).; For information about support of GraphQL APIs in the Akana developer portal, see GraphQL Support in the Developer Portal.
Introspection (GraphQL): GraphQL APIs include the ability to query a GraphQL schema for information about what queries it supports.; For more information, see https://graphql.org/learn/introspection/ (external site).
group: 1) The term "group" is used in many instances to refer to any of the following types of groups in the Akana API Platform: app teams, API Scope Groups, API Administrator groups, Site Administrator groups, or independent groups.; 2) "Group" is sometimes used specifically to mean an API Scope Group.
group administrator: For an independent group on the platform, the administrator has greater rights than a leader or member. For more information, see Managing Groups on the Platform. For an API Scope Group, the Administrator role is held by the API Administrator.
group membership request: An invitation to a specific user, whether a platform user or not, to join a specific platform group.
GTM: Acronym for Global Traffic Manager. A GTM is a DNS server, determining where to resolve requesting traffic to, based on location, load balancing, and possibly other factors.
GUID: Globally unique identifier for a resource (same as FDN). For more information about unique IDs used by the Akana API Platform, see IDs on the Platform.
gzip: A standard encoding method sometimes used to compress HTTP request or response messages.

H

HMAC: Acronym for hash-based message authentication code. The HMAC hashing algorithm uses a secret cryptographic key (symmetric key) to create a hash for message security. HMAC is used to verify data integrity and message authenticity. It can be used with cryptographic hash algorithms such as MD5 or SHA-1. Because it uses a symmetric key rather than the public/private public key infrastructure (PKI) approach, it delegates responsibility for the key exchange to the sender/receiver.
home page: A user who signs up to the Akana API Platform has a customized Dashboard which is that user's home page—the first page the user sees when logging in. A user who hasn't signed up doesn't have a home page.
hostname: In the context of an API, the hostname is the domain name or IP address for the API. The hostname might, or might not, include a port number. The hostname part of the URL does not include the scheme, which comes before, or the base URL, which comes after. Examples: acmepaymentscorp.com, api.example.com, example.com:8085.; For an example of the different parts of an API URL, see Base URL.
HTTP Artifact: One of the binding options supported by the SAML protocol. HTTP Artifact is useful in scenarios where the SAML requester and responder are using an HTTP user-agent and do not want to transmit the entire message, either for technical or security reasons. Instead, a SAML Artifact is sent, which is a unique ID for the full information. The IdP can then use the Artifact to retrieve the full information. The artifact issuer must maintain state while the artifact is pending.; HTTP Artifact sends the artifact as a query parameter.; The Akana API Platform currently supports this binding option for SAML responses, but not for SAML requests.
HTTP POST: One of the binding options supported by the SAML protocol.; HTTP POST sends the message content as a POST parameter, in the payload.; The Akana API Platform currently supports this binding option for SAML, for both requests and responses.
HTTP Redirect: One of the binding options supported by the SAML protocol.; When HTTP Redirect is used, the service provider redirects the user to the identity provider where the login happens, and the identity provider redirects the user back to the service provider. HTTP Redirect requires intervention by the User-Agent (the browser).; The Akana API Platform currently supports this binding option for SAML requests.

I

ICAP server

Internet Content Adaptation Protocol (ICAP) is a protocol that is sometimes used to extend a transparent proxy server for HTTP services. One common usage is to designate an ICAP server that provides virus scanning services.

The anti-virus policy provided by the platform's underlying infrastructure allows designation of an ICAP server that will provide anti-virus functionality. Once the policy is in place, messages are routed to the ICAP server, scanned, and forwarded only if they pass the scan.

identity (app)

When adding an app version, you can specify a custom identity name for the app version (Runtime Identity). If no custom value is specified, in response messages this property defaults to the reverse of the AppVersionID, with a dash. For example, if the AppVersionID is 6CYql2jSyfK9vaGZrvNkb7Am.acmepaymentscorp, the value for the Identity property will be acmepaymentscorp-6CYql2jSyfK9vaGZrvNkb7Am.

identity provider

An identity provider (sometimes abbreviated as IdP) is an entity responsible for verifying user identity and issuing identity information, usually in the form of a token. A common example is a website that allows users to log in using a Facebook or Google identity; in this scenario, Facebook and Google are identity providers. In OpenID Connect, the identity provider is called the Connect provider.

In terms of SAML, the identity provider verifies the identity of the user in response to a request by the Service Provider, and then responds with a SAML assertion.

IdP

In SAML, abbreviation for Identity Provider.

implementation (previously called environment)

See implementation (of an API) below.

implementation (of an API)

Different implementations of an API represent the different endpoints of the API in the same lifecycle stage. For example, it is common for an API to have Sandbox and Live implementations.

An app/API contract can apply either to the Sandbox implementation, which is a testing area, or the production implementation.

implementation pattern

The implementation pattern determines how the implementation is created, which also governs capabilities of the implementation. The platform supports the following options for implementation pattern:

Proxy: appropriate for a simple scenario where the API implementation has a 1:1 relationship with a back-end physical service/API.
Orchestration: appropriate for a more complex API implementation that might include one or more services, processes, or additional steps.

Note that if you change the pattern for an existing implementation, all data associated with the implementation is lost. For example, if an implementation has a pattern of Orchestration, with processes set up, and you change it to Proxy, the orchestration information is lost.

import

When information is exported from one instance of the platform to an export file (package file), it can be imported to another instance of the platform.

Only a Site Admin or Business Admin has permission to perform functions relating to import.

independent group

A group that exists independently of any single app or API. Any authorized user can create an independent group, and becomes the first administrator. The administrator can then invite other members and can remove members and change a member's role. There are three roles; admin, leader, and member. All members can see resources the group is linked to. Admins have full rights over the group. For more information, see Managing Groups on the Platform.

invitation code

A unique code generated and sent to a specific user in an email if a platform member invites the user to a platform group, such as an app team, API Admin group, or independent group.

This is one of the several types of codes use to manage user signup and login. For information on the others, see code (user).

J

jQuery: jQuery is an open-source cross-platform JavaScript library that simplifies the client-side scripting of HTML. The platform uses a JQuery plug-in to simplify file upload in some instances. For more information, refer to File Upload with Ajax.
JSON: An acronym for JavaScript Object Notation, JSON uses a subset of the JavaScript syntax to describe an object clearly and succinctly. One of the advantages of JSON over XML for API messages is that message content conveyed in the JSON format is much more concise than the same content conveyed in XML, consuming less bandwidth.
JSON Web Key: A JSON Web Key (JWK) is a JSON data structure that represents a cryptographic key (for example, an RSA key).
JSON Web Key Set: A JSON data structure that represents a set of JSON Web Keys.
JWK: See JSON Web Key.
JWT token (OpenID Connect): Acronym for JSON Web Token. In the context of OpenID Connect, a JWT token is a compact, URL-safe means of representing claims to be sent from one party to another over the web. The claims in a JWT are encoded as a JSON object that is used either as the payload of a JSON Web Signature (JWS) structure or as the plain text of a JSON Web Encryption (JWE) structure. This enables the claims to be digitally signed and/or encrypted.; The OpenID Connect Provider can issue a JWT token from either the Authorization Endpoint or the Token Endpoint. This is one of the two ways offered by the OpenID Connect specification for the app to learn information about the end user. The other is by publishing a UserInfo endpoint.

L

LaaS

Lifecycle as a Service (LaaS) is a set of products from Akana that exposes Lifecycle Manager asset configuration as a service/API. LaaS provides a way to integrate Lifecycle Manager functionality into Akana OAuth. Since Lifecycle Manager is more configurable, this facilitates the introduction of a more complex workflow, which can be used for purposes such as API governance.

LAAS includes two separate features:

Lifecycle Coordinator
Lifecycle Repository

label (for a ticket)

A label assigned to a ticket to indicate the ticket's priority rating. For valid values, see Ticket Label Values.

LDAP

Acronym for Lightweight Directory Access Protocol, an open, industry-standard protocol used by the platform to support single sign-on.

leader

In the context of an API Scope Group, a Leader has more capabilities than a group Member, but is not as senior as a group Admin. For more information, see What can a group Leader do?

legal document

In the context of the platform, a legal document is a document such as a developer agreement or user signup agreement that can be assigned to another resource such as an API version or a license. Documents are uploaded and managed using the Content service; once a legal document is assigned to a specific resource, such as an API version, a LegalDocumentID is assigned for that relationship.

For supported file types, see Legal Agreement Supported File Types.

license

A license is a tailored API access package designed by the Business Admin/API Admin and offered to the app developer. A license includes one or more license terms, each of which can include multiple scopes, giving access to specifically designated operations, and multiple quality of service (QoS) policies, and also one or more legal agreements applicable to the license.

license term

A license term is a rule that associates a set of QoS policies with a set of scopes within a license. For example, let's say a user wants a license that supports Unlimited access to READ, but no more than 10 requests per day for ADD/MODIFY/DELETE combined. In this example, two terms would be part of the license. One term has three scopes, ADD/MODIFY/DELETE with a QoS policy of 10 requests per day, and the second term has one scope, READ with a QoS policy of Unlimited. This license could be assigned to the application.

Lifecycle Coordinator

Lifecycle Coordinator is a separate configurable component that coordinates promotion across multiple instances of API Platform tenants. It can be deployed standalone or can be co-located with a tenant (or multiple tenants in the SaaS environment). Lifecycle Coordinator governs the promotion process and the transfer of data between environments.

Lifecycle Manager

Lifecycle Manager is a metadata repository and SDLC management product that enables enterprises to effectively collaborate between business, developers, and IT operations, resulting in rapid development and deployment cycles while increasing reliability, stability, and availability of their APIs and supporting assets.

Lifecycle Manager provides an intelligent inventory of assets and includes their relationships to each other, to the technical infrastructure, and to the company's business architecture. Through the use of Lifecycle Manager, organizations can accelerate reuse and SOA initiatives, as well as improve the governance over production and consumption of services and other reusable assets. Application developers, business analysts, and technical and business architects can search the repository for the company's SDAs, to identify those that best match business and technical requirements for application development and integration.

Lifecycle Repository

Lifecycle Repository is an add-on component, available for use with the Akana API Platform, that allows you to set up and use configurable properties, along with workflows based on those properties. Configurable properties are supported for the following resource types: API, App, and User.

limited-visibility app

The visibility setting determines the role a user must have, to be able to view the resource. For valid values, see Visibility Settings. For more information, see Public and Limited (Private) Apps.

listener

In general, a listener is an object that executes some code when triggered by an event. A listener monitors events happening in the program and acts based on how it's programmed to act in certain events.

In the context of the API platform, a listener is the server process that listens for and accepts incoming connection requests from client applications. Each deployment zone is based on an API Gateway; one or more listeners are defined for the API Gateway. The deployment zone can use one or more of the listeners defined for the API Gateway.

Policy Manager supports the following listener types: HTTP, HTTPS, JMS, AMQP. The Community Manager developer portal supports HTTP and HTTPS.

login

When a user logs in to the platform, the AtmoAuthToken_{fedmemberid} cookie is returned. Many API operations require login, which means that a valid cookie must be presented with the API request.

Depending on platform settings, login might also return the Csrf-Token_{fedmemberid} cookie, which you can use to create the X-Csrf-Token_{fedmemberID} header, required by many operations, particularly POST, PUT, and DELETE operations. See also:

To log in, use the See POST /api/login operation.

login domain

A domain that platform users can use to log in to the platform. The platform itself is a login domain, but a specific instance of the platform might support additional login domains, such as Google and Facebook. Login domains are defined by the Site Admin as part of initial setup. Once it is set up, a login domain name cannot be changed.

For more information on domains in general, see Managing Domains on the Platform.

M

MAC token: Acronym for Message Authentication Code. Used in OAuth 2.0, the MAC token is a security code that is typed in by the user of a computer to access an account or a portal. The code is attached to the message or request sent by the user. The MAC token attached to the message must be recognized by the receiving system in order to grant the user access. MAC tokens are commonly used in electronic funds transfer (EFT) transactions to maintain information integrity.
managed user: A platform user who was added by the Site Admin, using the POST /api/users operation or the user interface; as distinct from a user who signed up by creating a profile using the self-signup process, which is called a registered user. Differentiating between users in terms of how they are added allows the implementation of custom workflows that grant different privileges to different types of users. For example, the Site Admin could implement a custom workflow so that a managed user cannot change the user profile but a registered user can.
manifest: The Promotion Package holds the data that needs to be promoted from the Source Environment to the Target Environment. This includes the manifest, which holds summary information about the environment data in a format that the Promotion Coordinator understands. There might be several formats of environment data artifacts, but there is only one manifest format. The manifest holds the identifiers of all the objects and their relationships to one another in the environment data.
mark: Users can give positive feedback to items such as discussion topics and associated comments, reviews, and other resources such as tickets, using the Mark function. Choosing Mark provides positive feedback, in the same way as "Like" in Facebook®. The Mark value toggles on and off, so a user can mark or unmark a comment. In the user interface, the mark icon is a thumbs-up, and the unmark icon is a closed fist.
member: In the context of an API Scope Group, a group member has access to all information relating to the API and the group, including tickets and discussions. Members cannot invite additional members or change the status of other members. For more information, see What can a group Member do?
membership request (invitation): An invitation to another individual, whether a registered user or not, to join an Akana API Platform group or team such as an app team. API Administrators can invite others to be API Administrators; app team members can invite others to the app team. A Site Administrator, Private API Administrator, or Independent Group member can also issue a membership request in the same way.
mock service (API): A mock service is a specific type of orchestration that constructs the response based on a set of sample request/responses. A mock service is at an operation level, nor a service level.
model object (API): Model object is an informal term for a named grouping of discrete pieces of information. For example, in the Swagger Petstore example (http://petstore.swagger.io/), one model object is Pet, and contains pieces of information about a pet, such as name, unique ID, and tags.; POST and PUT operations often include model objects in the content being sent; GET operations often include model objects in the response being returned.

N

nonce: A nonce is a random string, uniquely generated by the client for each request. The nonce allows the server to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure-channel.
notification state: When a user first receives a notification, the notification state is Unread. Other valid notification states are: Read, Archived.

O

OAuth: OAuth is a popular Web security protocol that enables a user to grant permission to a third-party application to access the user's Web resources without sharing passwords or personal information. The third-party application first facilitates a connection to the holder of the Web resources so that the user can log in and approve the access. For example, User A could allow Site B, a subscription-only online training site, to have access to Account C, the user's credit card account, by authorizing a monthly debit of $25. User A would first sign in and approve the monthly debit. Site B could complete subsequent monthly debits without further interaction with User A; however, User A could cancel the access at any time. OAuth has been likened to a valet key on a car which gives access to certain features of the car without giving full access.; Essentially, OAuth allows a web-based or mobile application to use an API exposed by another web or mobile application without sharing passwords.
OAuth access token: In OAuth, an access token is essentially a pass, a credential that gives authorization to access the requested and approved resource or resources for as long as the access token remains valid. In some cases, access tokens can be renewed by means of a refresh token; in some cases, they cannot. For more information, refer to the OAuth 2.0 specification (external site).
OAuth authorization code: With the OAuth 2.0 Authorization Code grant type, the resource owner (consumer; for example, the app user) is redirected to the authorization server and gives authorization for the app to access the resource. The authorization server then redirects the consumer back to the client app with an authorization code. The client app presents this authorization code, along with the app's authentication credentials, back to the authorization server, requesting an access token (and optionally a refresh token). The client then uses the access token to call the service on behalf of the resource owner. A refresh token can be used to extend the lifetime of this session.; An Authorization Code is a short-lived token issued to the client application by the authorization server upon successful authentication/authorization of an end-user (resource owner). The client application then uses the authorization code to request an access token from the authorization server.
OAuth authorization endpoint: The endpoint for the OAuth Authorization Server. This is the endpoint on the authorization server where the resource owner provides credentials, such as username and password, in and grants authorization to the client app to access the resources or a specified subset of the resources.; When setting up an OAuth domain, Site Admins must specify this value. Additionally, if an API is using a third-party OAuth provider rather than an OAuth domain set up on the platform, the API Admin must specify this value in the OAuth setup wizard.; Users connect to the authorization endpoint; apps connect to the token endpoint.
OAuth authorization server: In an OAuth implementation, the authorization server collects the resource owner's credentials, gets the resource owner's permission for the app to access the resources, and passes back the authorization token to the app so that the app can then access the resources.
OAuth authorization server URL: As part of setting up the OAuth domain, the Site Admin must specify the Authorization Server URL. This is the URL that the browser for the resource owner (app user) will be accessing for the OAuth grant. It is the URL at which the OAuth Provider accesses the requests, for both Authorization Endpoint and Token Endpoint.; The URL must be accessible to all the apps and end users that might use APIs that are referencing the OAuth domain. The Authorization Endpoint and Token Endpoint for OAuth 1.0a and OAuth 2.0 will use different paths according to the specific OAuth version. Firewalls and DNS servers must be set up for this URL so that end users and apps can access the URL.
OAuth callback URL: Redirect URL. The URL to which the API sends the response message with the token.
OAuth grant types: OAuth 2.0 supports four different grant types; each has a different process flow. Grant types are designated as 2-legged or 3-legged depending on the number of parties involved. The 2-legged grant types are Client Credentials and Resource Owner Password Credentials; the three-legged grant types are Authorization Code and Implicit. The platform also supports an extension grant type.
OAuth grant types: 2-legged: The number of legs used to describe an OAuth request refers to the number of parties involved; 2-legged or 3-legged. When the client is also the resource owner, it is a 2-legged flow. OAuth 2.0 includes the following 2-legged grant types; Client Credentials and Resource Owner Password Credentials.
OAuth grant types: 3-legged: The number of legs used to describe an OAuth request refers to the number of parties involved. The most common process flow includes three parties; a client, a server, and a resource owner. This is a 3-legged flow. OAuth 2.0 includes the following 3-legged grant types; Authorization Code and Implicit.
OAuth grant types: Authorization Code: A 3-legged OAuth 2.0 grant type: An authorization code is returned to the client through a browser redirect after the resource owner gives consent to the OAuth Authorization Server. The client then exchanges the authorization code for an access token. Resource owner credentials are never exposed to the client app.
OAuth grant types: Client Credentials: A 2-legged OAuth 2.0 grant type: The client presents its own credentials to the OAuth Authorization Server in order to obtain an access token. This access token is either associated with the client's own resources, rather than a specific resource owner, or is associated with a resource owner for whom the client is otherwise authorized to act.
OAuth grant types: Implicit: A 3-legged OAuth 2.0 grant type: An access token is returned to the client through a browser redirect in response to the resource owner authorization request. This grant type is suitable for clients that do not support keeping client credentials confidential (for use in authenticating with the OAuth Authentication Server) such as client applications implemented in a browser using a scripting language like JavaScript.
OAuth grant types: Resource Owner Password Credentials: A 2-legged OAuth 2.0 grant type: The client collects the resource owner's password and exchanges it at the OAuth authorization server for an access token, and often also a refresh token. This grant type is suitable in cases where the resource owner has a trust relationship with the client, such as its computer operation system or a highly privileged application, since the client must discard the password after using it to obtain the access token.
OAuth grant provisioning UI: In the platform, the OAuth grant provisioning UI is the HTML page, used in Test Client, where the resource owner signs in and authorizes access, for the purposes of using Test Client.; The grant provisioning UI has the potential to include the logo for the application, pulled from the application information, and for the OAuth provider, as set up in the Branding tab in the OAuth Provider domain setup.
OAuth Provider: The platform’s OAuth Provider add-on fulfils all aspects of the OAuth Authorization Server role.
OAuth refresh token: In OAuth 2.0, certain grant types support use of refresh tokens to facilitate longer access periods. This is useful in scenarios that extend over time, such as a regular monthly payment amount.; In OAuth 1.0a, once an access token is generated it is valid until revoked by the user. OAuth 1.0a does not support refresh tokens.; OAuth 2.0 introduces expiration of access tokens and adds a second type of token, a refresh token, that can be used in conjunction with the access token to allow users to give long-term permissions but yet maintain security. This process helps ensure that if a specific access token is compromised, a new one can be generated from the refresh token, which can be stored in the database on the server.; The access token grants immediate access but only for a limited time. The access token comes with two additional values: expires_in, which indicates the life of the access token, and refresh_token which can be used to get a new access token when the current token expires. Additional user approval is not needed, but the expiration and renewal add security to the process. When (or before) the access token expires, the refresh token can be used to generate a new access token.
OAuth resource owner: The end-user who is authorizing an application to access his/her resources for a specific purpose.
OAuth resource server: The server where the resources are stored. The resource server accepts requests and responds to approved requests using access tokens.
OAuth response_type parameter: Indicates instructions about the type of response expected for the OAuth/OpenID Connect message. This determines what parameters are returned from the endpoints used. See also OAuth Parameters (article in OAuth documentation).
OAuth scope: In the context of OAuth or OpenID Connect, a scope defines a set of one or more resources that the resource owner is granting access to. For a standard definition in the context of OpenID Connect, see http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint.
OAuth token endpoint: In OAuth 2.0, the token endpoint is the endpoint on the authorization server where the client app sends the authorization code, client ID, and client secret and receives in exchange an access token which allows the app to access the approved resources.; The token endpoint first authenticates the client application. It then allows the client application to send the code received from the authorization endpoint; in exchange, it generates an access token and sends it to the client application.; Users connect to the authorization endpoint; apps connect to the token endpoint.; For more information, see the OAuth 2.0 specification (external site).
OpenID: OpenID is an open standard for authenticating users. It can be used for access control and allows users to log on to different services with the same digital identity where these services trust the authentication body. OpenID simplifies the authentication process because there is only one username and password to remember. For more information, refer to the Site Admin help.; Since Google has now deprecated OpenID support and OpenID Connect is being adopted by the industry, it is better to switch to OpenID Connect.
OpenID Connect: An identity layer on top of the OAuth 2.0 protocol that allows the client to verify the identity of an end-user based on authentication by an authorization server. OpenID Connect was released in February 2014 and is gaining popularity. For example, Google is moving from OpenID to OpenID Connect for products such as the Google+ API, used by the platform's Google login domain. For more information, see Welcome to OpenID Connect (external site).
OpenSearch: OpenSearch is a widely used set of technologies that sets standards for the publishing of search results. For more information, see Paging of Returned RSS Items.
operational policy: A policy that defines requirements for addressing the operational implications of services that are shared across enterprise departments. These policies address the operational model for services, capacity monitoring and planning, the handling of policy exceptions and violations, and service execution including the definition and enforcement of runtime policies such as security, access, logging procedures, and service reliability.
orchestration (API): An orchestration creates a service that is implemented with a process, rather than being simply a proxy of another service. The orchestration process itself might (but does not necessarily) invoke multiple APIs, and might aggregate responses or take other actions to process a request. A mock service is a type of orchestration. An orchestration is at an operation level, not a service level.
organization: In the context of the Akana API Platform, an organization can represent any of several different types of organizational entities, such as a company, department, project, or partner.
overloaded operation (API): An overloaded operation is one that has two or more implementations that have the same basic URL but with different arguments or, commonly, different media types. Often, there might be two operations that share the same path and HTTP verb but have different media types for Consumes (request media type) and Produces (response media type) elements.; For example, the platform API itself has a small number of overloaded operations that take a response media type of application/json or application/xml to return the response information in the form of an RSS channel, and the same path and verb with a media type of application/vnd.soa.v81+json or application/vnd.soa.v81+xml returns the response information as a model object in JSON or XML format.

P

package file: The ZIP file that is created as a result of using the export function. The package file can be imported into another instance of the platform by a Site Admin or API Admin.
partial API visibility: API visibility for the app developer is restricted to a subset of the API; only certain portions of the API documentation/operations can be seen by the app developer.
password reset code: See reset code.
physical service: A physical service is an API service external to the platform which is not hosted on the platform, but which is set up so that platform APIs can reference it. A platform API that's set up to use orchestration can reference a physical service in a process or script as part of the orchestration.
physical service endpoint: The physical service endpoint is the actual endpoint for the API.; When an API is set up as a proxy API (the default), the platform acts as a proxy. Apps send messages to the proxy endpoint and the platform processes the messages and relays them to the physical service endpoint, the actual API endpoint. In this scenario, the physical endpoint is not exposed to API users; only the endpoint for the proxy service, also called virtual service, is exposed.; When an API is set up as a proxy API, in the background there are two services: the physical service, with the actual API endpoints, and the virtual service, where the platform receives messages, applies policies etc. before sending the messages on to the physical endpoint.; When an API is set up as a physical service, messages for the physical service endpoint are just passed through.
PingFederate: A federated identity management system based on the SAML protocol. PingFederate® supports SSO, SLO, and other federated identity standards. It can also be used as an OAuth 2.0 provider.; The platform supports PingFederate provider as a domain type (set up by the Site Admin).
pipes (data format): A data format that uses the pipe character (|) as a separator between values. Pipe separators are sometimes used for tabular data exchange.
PKCS12: A file format used for keystores. The private key and certificate can be stored in the same PKCS12 file. In the platform, this format is used for uploading the app keystore file in Test Client. The file extension can be p12 or pfx.
Postman: A free external Web client application used for testing APIs. See https://www.getpostman.com/postman.
Private API: An API that is designated with a visibility of Limited. A Private API and all content associated with it including documentation, discussions, tickets, and reviews is invisible to all users who are not specifically authorized to view it. Only Administrators and members of API Scope Groups that have specifically been granted access can see the Private API.
Private API Group: See API Scope Group.
private resource: A resource that is designated as Private can only be accessed by authorized users. A Private API can only be seen by an API Administrator, API Scope Group Member, business administrator, or site administrator; a Private App can only be seen by app team members and the business or site administrators; a Private Group can only be seen by invited group members and the business or site administrators.
process: In the context of the API Platform, a process is an ordered group of activities that can be performed by an API Gateway that supports the virtualization capability.
promotion (from one environment to another): Promotion is the process of propagating changes made in one Environment to another. The Promotion process is automated for efficiency and to help prevent mistakes that could occur in a manual process. Promotion is managed via the Promotion Coordinator.; Promotion requires installation and configuration of the Lifecycle Coordinator feature.
Promotion Coordinator: A Promotion Coordinator is a separate component that controls the promotion process and transfer of data between environments. There is a single Promotion Coordinator for all Environments.
promotion package: The Promotion Package holds the data that needs to be promoted from the Source Environment to the Target Environment. The package contains two different artifacts: the environment data and the manifest.
proxy API: When you set up your API on the Akana API Platform and choose to use the Proxy feature, all traffic to your API endpoints is channeled via the platform. This offers significant benefits, including the ability to apply policies and monitor traffic at the proxy.
public app: Any viewer looking at the Community Manager developer portal can view a private app. Login is not needed unless the Community Manager developer portal itself is secure.; The visibility setting determines the role a user must have, to be able to view the resource. For valid values, see Visibility Settings.
public key integration (PKI): When a user registers an app in the Akana API Platform, the Shared Secret security option is the default. App owners who want to use Public Key Infrastructure (PKI) for secure message signing must specify Public Key Integration as the security option in the Akana API Platform user interface, on the App Details page.; To implement PKI, the app owner must get a public/private key pair, upload the public key to the Akana API Platform, and use the private key for signing the API requests. The Akana API Platform API verifies each incoming request using the public key.
public profile (app): An app's Public Profile screen allows the app owner to brand the content of the OAuth Authorization screen. It is presented to external end-users of an app, and is used to grant an app rights to use an API. The OAuth Authorization screen applies to all apps.

Q

QName: A unique identifier used for certain elements and attributes (Qualified Name). The Community Manager developer portal API uses QNames to identify elements such as API bindings and interfaces. Policy Manager also uses QNames.; QNames are used to create a mapping between a URI and a namespace prefix. The QName includes the object's unique name within the namespace, plus the namespace itself.
QoS policy: Quality of Service policy. A QoS policy defines the level of service being offered to an app that is accessing an API; for example, the number of transactions per minute that are allowed for the app. In the platform, QoS policies are tied to license terms.

R

RabbitMQ: An open-source message broker software that implements the Advanced Message Queuing Protocol (AMQP). The underlying infrastructure can be configured to use AMQP.
RAML: Acronym for RESTful API Modeling Language. RAML is a language based on YAML, and is used for describing RESTful APIs.
rating: The API platform allows users to rate certain resources, such as apps, APIs, and groups, clicking from 1 (lowest rating) to 5 stars (highest rating).
RDN: Acronym for Relative Distinguished Name—a unique identifier assigned to a platform member. In a non-federated scenario, the RDN is sufficient as a unique identifier for each member. See also FDN.
realm: A pattern that represents the part of URL-space for which an authentication request is valid. In OpenID or OpenID Connect, a realm is designed to give the end user an indication of the scope of the authentication request. The identity provider must present the realm when requesting the end-user's approval for an authentication request. The realm must be used by the identity provider to uniquely identify the relying party.
refresh token: See OAuth refresh token.
registered user: A platform user who signed up by creating a profile using the self-signup process, as distinct from a user who was added by the Site Admin, using the POST /api/users operation or the user interface, which is called a managed user. Differentiating between users in terms of how they are added allows the implementation of custom workflows that grant different privileges to different types of users. For example, the Site Admin could implement a custom workflow so that a managed user cannot change the user profile but a registered user can.
registration code: A unique code generated and sent to a specific user in an email if the Site Admin adds the user (currently supported only via the API). The code is only valid for the account it is generated for, and expires after a pre-set period.; This is one of the several types of codes use to manage user signup and login. For information on the others, see code (user).
relying party: In OpenID and OpenID Connect, the service provider is called the relying party. The relying party trusts the Connect provider to authenticate the user. In the context of the Akana API Platform, the platform is the service provider and the Site Admin sets up the Connect provider in Domains setup.
reset code: A unique code generated and sent to a specific user as a result of a password reset request. The code is only valid for the account that requested it, and expires after two days.; This is one of the several types of codes use to manage user signup and login. For information on the others, see code (user).
resource (UI): In the context of the platform, the term UI resources includes all code-related components such as JavaScript files, templates, and stylesheets.
resource (OAuth): In the context of OAuth, a resource is something that the resource owner has full rights to, and can grant permission to, so that the application can perform some function on the resource, for the benefit of the resource owner. Examples: a Facebook calendar, a specific user's photo collection on a photo sharing website, a bank account.
resource (platform): In the Akana API Platform, a Resource is an item, such as an App or API, which has its own Board and set of activities. There are six resource types: API, app, business, contract, group, and user. In some instances, an app or API version is treated as a separate resource, since there might be multiple versions for a single app or API. In the platform API, scopes are also called Resources.
Resource ID: The unique ID for a specific resource; for example, the ScopeID or the APIVersionID.
restricted API access: Restricted access for an app means that the app's access to the API is restricted to a subset of the API, as defined by scope mapping, or to a specified, agreed-upon quota as defined by a QoS policy. Compare: unrestricted API access.
review: Users can write reviews for any apps, APIs, or groups that they have access to. In the Community Manager developer portal, reviews are created from the Details page for the resource. Each review includes a subject line and a comment.; Other users can comment on the review, and can mark reviews that they like.; Depending on the platform configuration, reviews might be moderated. If so, the review must be approved by an Administrator before it is published.; A review is actually a board item (forum entry) even though, in the user interface, reviews are not displayed on the Board for the resource, but instead are displayed on the Details page.; In terms of using the API, all operations that work for Board items work for reviews also.
role: Within an API Scope Group, each group member has a role, as Member, Leader, or Admin. An API Admin cam invite team members and designate roles.; Within an independent group, each group member has a role, as Member, Leader, or Admin. A Group Admin can invite or remove other team members and designate roles.; Other roles on the platform include App Team Member, Site Admin, API Admin/API Administrator (same role), and Site User. For more information about roles, see What are the default roles for the API platform?
RSA: A popular and secure public key cryptography algorithm.
RSS: RSS is a widely used technology that allows users to subscribe to website content they're interested in. Once users subscribe to RSS feeds, updated content is automatically delivered to them in the form of an RSS channel, without the users having to check the individual websites for updates.; In the context of the Akana API Platform, many GET operations return the results in the format of an RSS channel. For more information, see RSS Channels on the Platform.
RSS channel: The format in which information is conveyed using the RSS technology is called an RSS feed, web feed, RSS channel, or RSS document. It includes full or summarized text plus metadata (information about the text).; Many of the operations in the Akana API Platform API use RSS in the response. In general, GET methods that return any type of list return the information as an RSS channel, usually in either JSON or XML format as specified in the request message.; For more information on how the Akana API Platform uses RSS channels, see RSS Channels on the Platform.

S

same-origin policy: Most browsers enforce the "same origin policy" security policy, which means that the parent window and an iframe can communicate only if they have the same domain name. It's a security measure to help prevent malicious activity. For information about how the platform works with this policy, see File Upload with Ajax.
SAML: Acronym for Security Assertion Markup Language. SAML is an identity federation standard that enables single sign-on. It is an XML-based standard for exchanging authentication and authorization data between a service provider (providing a service to the user) and an identity provider (providing user identity verification for the service provider).; One usage, in the context of the platform, is by OpenID Connect where it is used to provide single sign-on. The platform acts as the relying party.
SAML Artifact: A unique ID used by the service provider and identity provider to reference a specific user session or transaction. The SP can use the Artifact to query the IdP for information about the user.
SAML assertion: A SAML assertion is an XML document returned by the Identity Provider to the Service Provider after authentication of the user. The assertion has a very specific structure, as defined by the SAML standard. A SAML assertion has a {Subject} element which contains information about the user. It might have conditions and attributes associated with the information being conveyed. It is digitally signed and asserts that the user has been authenticated.; Note: the above definition applies to an authentication assertion, which applies in the context of the platform’s support of SAML. There are other types of SAML assertions.
SAML Web SSO: Single sign-on over the Web using the SAML protocol.
scheme: In the full URL for an API, the scheme is the transfer protocol; most commonly HTTP or HTTPS.; For an example of the different parts of an API URL, see Base URL.
scope: A scope value for an API version defines a subset of resources to which permission can be independently granted. In addition, the permission granted can be controlled by visibility (permission to view) or access (permission to send messages, to either the sandbox or production endpoint).; Defining scopes for an API allows the API administrator to control the granularity of API access granted to an app. When scopes are defined, app owners can request access to specific resources they want to access, and API owners can grant access to specific resources they want to share.; In the platform API, scopes are also called Resources. A ResourceID is a unique ID for a scope.
scope (OAuth): For information on scopes in the context of OAuth, see OAuth scope.
scope group: See API Scope Group.
scope mapping: If an API is using the Licenses feature, scope mapping is the key to defining which portions of your API will be available for which licenses. The scopes and licenses themselves are defined by the Business Admin, but at the API level the API Admin determines which operations are assigned to which scopes. This in turn determines which licenses will be available to app developers requesting access to an API.; In the Akana API Platform API, scope mapping is specified using the PUT /api/apis/versions/{APIVersionID}/resources operation.
script: In the context of the API Platform, a script is a reusable sequence of commands that can be used to automate the execution of tasks associated with managing the platform and its resources.; You can build scripts for automating common tasks relating to your APIs. You can build a library of reusable scripts, which you can then import into a process.
search visibility: See visibility (API) and visibility (app).
security challenge question: See challenge question.
Server Name Indication (SNI): An abbreviation for Server Name Indication, SNI is an extension of the TLS protocol that allows a single server to connect multiple SSL certificates to one IP address. When the client attempts to connect to the server, the client indicates the hostname it is attempting to connect to. The server sends the applicable digital certificate, which the browser then verifies; upon verification, the connection goes ahead.; The API platform's support of SNI means that multiple certificates can be used for one HTTPS endpoint. This means that each API can use its own certificate for its own clients. The deployment zone must support HTTPS; the API implementation must have the Use Implementation's Key/Certificate for SSL option checked in the HTTPS tab for the deployment, and there must be a certificate in place for the implementation.; For general information on SNI, see https://en.m.wikipedia.org/wiki/Server_Name_Indication.
service-level policy: A specific type of Quality of Service (QoS) policy that defines conditions for measuring and reporting performance for a specific contract.
Service Provider: In terms of SAML, the Service Provider (SP) offers a service to the user and allows the user to sign in by using SAML. When the user attempts to sign in, the SP sends a SAML authentication request to the Identity Provider (IdP). The IdP validates the request, authenticates the user, and creates a SAML assertion that represents the user’s identity and, in some cases, sends additional information about the user in the form of associated attributes. The SAML assertion is digitally signed and encrypted and then sent back to the service provider that initiated the request.; Identity federation software at the SP receives the assertion, verified the authenticity, decrypts, and shares the information with the application.
SHA-1: SHA-1 is a cryptographic hash function, broadly used and trusted.; When you hash a value with SHA-1, the hash function returns a 160-bit string. This is the message digest. The value is hashed and sent with the message; at the receipt point, the value is hashed again, and the two hash values are compared. When the two hash values match, it is a secure, reliable indication that the message hasn't changed; the message at the receipt point is an accurate duplication of the message at the send point.
SHA-256: Part of the SHA-2 family of algorithms developed by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) to succeed SHA-1. Each is named according to the number of bits in the output; so, whereas SHA-1 has 160 bits in the hash output, SHA-256 has 256.
shared secret: When you register your app, the AppID and Shared Secret are automatically generated. The Shared Secret is a binary hashed value, generated within the secure environment of the Akana API Platform and known only to you and to the Akana API Platform. On your app's Details page, in the Security section, you'll see that the Shared Secret option is the default security mechanism.; The Shared Secret approach follows the WS-Security digest authentication mechanism.; In some scenarios, the app might have a user-defined App Identity that includes a domain. In this case, the platform does not collect, regenerate, return, or display the Shared Secret value. Instead, the user manages it in the external identity domain, which must be a valid domain set up in the platform. The platform takes the Shared Secret value that the user provides and validates it with the external identity domain.; For this to occur, the platform's App Settings must allow user-defined identity (this includes ID and Shared Secret), and the user identity must be set to a value of {LoginDomain}\{LoginDomain-UserName}, where {login-domain} is the platform's ID for a valid login domain set up on the platform, LoginDomain-UserName is a valid account on that login domain, and they are separated by a backslash. The platform validates the LoginDomain ID and does nothing with the Shared Secret value except validate it at runtime when it's provided by the user.
signup code: A unique code generated and sent to a specific user in an email when the user signs up for the platform. The code is only valid for the account that requested it, and expires after seven days.; This is one of the several types of codes use to manage user signup and login. For information on the others, see code (user).
site administrator: An individual who has responsibility for keeping the site running smoothly. Site administrators have greater access rights than normal users. There can be more than one site administrator. For more information, see Managing Groups on the Platform.
SMSESSION cookie: An authentication cookie used by CA SiteMinder. The CA SiteMinder product implements single sign-on by means of this encrypted cookie.
SNI: See Server Name Indication (SNI).
soapUI: A free (or paid) application used for testing APIs. See https://www.soapui.org/.
SP: In SAML, abbreviation for Service Provider.
SSO: Acronym for single sign-on. SSO login allows a user to sign on to one software system using access credentials granted, and validated, by another system.; In the platform, an example of SSO login is the ability to sign on using Facebook or Google credentials. Note that whether an instance of the platform allows SSO login, and which providers are supported, is configurable, as determined by the Site Admin.; For more information about SSO login, refer to Managing SSO Login on the Platform.
SSV: Space-separated value format, a data type for certain API input parameters. This format is commonly used for exporting tabular data. Used in API documentation generated with Swagger 2.0: see http://swagger.io/specification/.
state: 1) App version state: The current state of the app. Possible values: Initial, Sandbox, Review, Approved, Live.; 2) API state. The current state of the API. See API States.; 3) Notification state: See notification state.; 4) Legal document state: See legal Document States.; 5) License state: See License State values.
status: Individual resources have a status which might include such items as open connection requests, open trouble tickets, number of active consumers, number of active discussions, and number of unresolved alerts. Different resources have different status items.
support board: A user-defined board that comes with portal installation and is open to all users for discussions. The ID for the Support Board is supportboard.{FedmemberID}, and the URL is: http://{hostname}/api/boards/supportboard.{FedmemberID}.
Swagger: A third-party tool provided by the platform for automatic generation of API reference documentation. Swagger is a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services. It produces dynamically generated documentation from the information provided in the API definition. When a user defines an API, the structure is dynamically generated and added to a predefined Swagger template (resources.swg). The API Admin can then add title, description, implementation notes, and parameter information. The documentation displayed to the user is a blend of automatically generated content (Swagger resource file) and user-generated content (Swagger properties file).
Swagger properties file: Once the Swagger documentation is generated, the user can add comments and additional information. This information is stored in a Swagger properties file named {APIVersionID}.properties; for example, apiversion17171.acmepaymentscorp.properties. When a user views the API documentation in the platform, the user sees a merged combination of the automatically-generated Swagger resource documentation and the user-generated information stored in the Swagger properties file.
Swagger resource file: The automatically-generated API documentation file generated by Swagger based on the API definition. See Swagger.
system board: One of the types of Forum (Board) that are part of the portal. The App Version Board, API Version Board, and Group Board are system boards.

T

tag: A tag is essentially a keyword or key phrase that's added to a piece of content, or information associated with a resource, to assist in search results. Several different types of resources can have tags assigned to them; for example, apps, APIs, groups, and tickets. Multiple tags are separated by commas.; For example, if an app is a movie general knowledge game, the app owner might assign tags of movie, game, general knowledge; or an API owner can add a category or product line to the metadata for certain APIs so those APIs will come up in search results for that term.
target API: When defining an API on the platform, if an API is using the platform as a proxy, the Target API defines the destination ("next-hop") endpoint for the API.
target URL: The URL for the target API. The target URL is the endpoint for the implementation; the destination ("next-hop") endpoint for the API.
tenant: When you log in to an instance of the Community Manager developer portal, you are logging in to a specific tenant. In the context of the Community Manager developer portal, each tenant has its own URL and its own set of apps, APIs, businesses, and groups. Configuration settings in the Community Manager developer portal apply to the current tenant. The tenant is a distinct Community Manager developer portal and community that has a logical separation from any other communities that might be hosted in the same product instance. A tenant might be a customer that is hosted within a shared system, such as the Akana SaaS platform, but has separation from other customers/ tenants.
Test Client: The platform includes an API testing interface, Test Client, that acts as an easy-to-use testing tool for any API that is set up in the Community Manager developer portal. This test tool allows developers to thoroughly test all capabilities of the API.; It can be used for prototyping, testing, and troubleshooting apps against an API. It includes OAuth support for retrieving the OAuth token in order to process the message.
theme: One instance of the portal. More than one theme can be defined during the installation process and can then be customized for different purposes or audiences. Each theme has a separate URL.
third-party account (email): The platform supports login through a third-party identity provider, such as logging in with a Google, SAML, or LDAP account.
ticket: A type of feed entry, representing a trouble ticket created to raise an issue with a resource (app or API) or a connection. Tickets are typically created by a consumer of an API. Any member of the community can comment on a ticket, but it can only be marked as Resolved by the original creator or by an administrator of the target resource. For example, if Joe writes a ticket about an issue with the SkyBlue API, only Joe or the SkyBlue API Admin can mark the ticket as Resolved.
tModel: Abbreviation for Technical Model. A tModel is a data structure that resembles a type of XML web service. tModel is a core component of UDDI. A tModel represents a unique concept or construct, and is used to describe compliance with a specification, concept, category, identifier system, or shared design. Each tModel should include a URL to a document that describes the tModel in greater detail.
token: An access object sent to the requestor (client app) after authentication is complete and authorization has been granted. The token enables the client app to request access to the end-user's resources. OAuth, OpenID Connect, and SAML use tokens. There are different types of tokens, as defined in the applicable specification; for example, access tokens and bearer tokens.
token endpoint (OAuth): See authorization token endpoint.; The token endpoint first authenticates the client application. It then allows the client application to send the code received from the authorization endpoint; in exchange, it generates an access token and sends it to the client application.; Users connect to the authorization endpoint; apps connect to the token endpoint.
transaction: In the context of the Akana API Platform API, a transaction is one instance of an app making a call to an API.
TSV: Tab-separated value format, a data type for certain API input parameters. TSV format is used for tabular data exchange.
time to first byte (TTFB): The TTFB for an API request is the amount of time that it takes from when the request is received from the client app to the first byte of data returned from the API Gateway to the client app.; In the context of the Community Manager developer portal, TTFB metric breakdowns are shown in the API Logs page.
TTFB: See time to first byte (TTFB).
two-factor authentication (2FA): An enhanced security feature for additional authentication of users logging in. The first factor, something the user knows, is satisfied by the user entering credentials, such as username and password, to authenticate. A second factor can be something the user has, such as a passcode. The platform has an optional feature to support two-factor authentication, commonly called 2FA. If this feature is enabled, after verifying credentials the user is sent a code, usually by email, and is directed to a platform page for entering the code.

U

uddi: Acronym for Universal Description Discovery and Integration. UDDI is an open industry initiative sponsored by OASIS. It enables businesses to publish service listings and discover each other, and allows them to define how their services or software applications interact over the Internet.
uddi key: Each entity in a UDDI registry is assigned a key, which uniquely identifies that entity within the registry. Various parts of an API registered in the platform have unique UDDI keys assigned in Policy Manager; for example, the BindingKey and InterfaceKey.
unmark: To unmark a discussion, ticket, comment, or other resource means to remove a mark previously placed on the resource. In the user interface, the mark icon is a thumbs-up, and the unmark icon is a closed fist.
unrestricted API access: Unrestricted API access for an app means that the contract is not limited to a specific license. The app has full access to all operations of the API. Compare: restricted API access.
user: A person with a registered login ID to the Akana API Platform. All users must complete the registration process so that the system can gather required information about them before granting access. Each user can choose to define a new username/password combination that will be managed within the Akana API Platform, or can leverage the integration of Akana API Platform with external security providers such as Facebook® for authentication. By completing the signup process, each individual is assigned the role of User; users can then assume other roles, such as API Administrator or App team member (depending on platform settings).; Note: To use the Akana API Platform API, users must sign up with the Akana API Platform rather than using a third-party authentication provider.
user-defined forum (board): A platform Forum (Board) which is additional to the standard system boards that come with the platform (such as the app and API forums); a custom forum, defined as part of site customization. The Support Forum is considered to be a user-defined board.
UserInfo Endpoint (OpenID Connect): One of the two ways offered by the OpenID Connect specification for the app to learn information about the end user. The OpenID Connect Provider can publish a UserInfo endpoint, which is a protected resource that returns claims about the authenticated end-user.; The client sends a request to the UserInfo Endpoint using an access token. The UserInfo Endpoint returns the user info to the client app.; The OpenID Connect Provider can issue an ID Token (JWT token) from either the Authorization Endpoint or the Token Endpoint.
UTC: See Coordinated Universal Time (UTC).

V

vanity hostname: A vanity hostname is generally memorable, easy to understand, and clearly identifiable. An API might have an actual hostname that has more complexity, but maps to a vanity hostname that's easy for customers to remember. Customers can use the vanity hostname and do not even need to be aware that it isn't the actual API processing endpoint. The vanity hostname cannot include the underscore character.
version: Each app or API on the platform much have at least one version, and can have multiple versions. When a user creates an app or API on the platform, the first version is created automatically; when using the API, it's important to complete both actions. If there is only one app or API version, deleting that version also deletes the app or API.
viewer: A Group that has a connection to a Private API. Members of the group have access to the Private API as long as the connection between the group and the API exists, and can see information about the Private API such as documentation and discussions. In future versions of the platform, the definition of Viewer might extend to individual users or businesses.
virtual service: For an API that's hosted on the platform (proxy API), all traffic to the API endpoint is channeled via an endpoint provided by the platform. API users send messages to the virtual service endpoint (for example, http://ubu1464qa-10.local.akana.com:7905/api88887live). From there, policies are applied and the messages are directed to the physical service endpoint (for example, www.api.example.com).
visibility: A setting that controls the types of users who can see an object, such as an app, API, group, license, or scope, and any associated items such as discussions and tickets. See below: visibility (API) and visibility (app). For more information about visibility values, refer to Visibility Settings.
visibility (API): A setting that controls the types of users who can see an API and its associated items such as discussions and tickets. Possible values are Public, Limited, or Registered Users (see Visibility Settings). A discussion about a Limited (Private) API can only be seen by administrators and API Scope Group members associated with that API. Users must be a member of an API Scope Group associated with the API or invited to be an Administrator for the API, and must then accept the invitation, before they even see the API in the Akana API Platform.
visibility (app): A setting that controls the types of users who can see an app and its associated items such as discussions and tickets. For valid values, see Visibility Settings.

W

workflow: Workflow defines the sequence of steps that are followed in a business process, including such related data as conditions (for example, a ticket must be resolved before it can be closed), state (for example, a ticket can have states of Open, Resolved, and Closed), or role (for example, a certain step can only be completed by an Administrator).; Defining the workflow for a business process gives you control over the process and allows you to monitor and customize as needed to streamline the business process.; The platform includes default out-of-the-box workflows for certain resources, such as API contracts, and allows you to customize the workflow for several key resources.
workflow action: Certain types of activities on the platform must be done in a specific sequence. These are often managed by workflows. Each workflow action changes the state of the resource. Some examples of workflow actions are: requesting or approving an API contract, sending a group membership invitation, or changing the status of a ticket.
workflow definition key: A unique ID is assigned to each custom workflow when it's uploaded to the platform. Example: 2597f44e-8f1c-4cc4-8019-69781dd1a0d8. The workflow definition key for a resource, such as apps, APIs, or groups, indicates the custom workflow that's specified as the default for settings governing that type of resource.; The workflow definition key is returned when the workflow is added. If you're not sure of the workflow definition key, you could run the GET /api/workflow/definitions operation to get a summary of all workflows that exist. However, the response doesn't include the key. You could also run the applicable GET operation to return the workflow definition key for the current workflow, for the particular object type. For example, to get the workflow definition key for the current workflow in place for API versions, run the GET /api/businesses/{BusinessID }/apisettings operation.
WWW-Authenticate response header: A standard HTTP response header used as part of the authentication process used in Akana API Platform API calls. When the server receives the request message, it challenges the client for valid authentication via the WWW-Authenticate response header. The client returns the authentication information in an Authorization header. The server validates the client information and then acts on the request message.

X

X-Csrf-Token_{fedmemberID} header: A custom header used by the platform to protect against CSRF attacks. For more information, see CSRF Prevention on the Platform. For information about the FedmemberID that's used in the header, see IDs on the Platform.
X-Forwarded-Host header: In OAuth Provider scenarios that include a reverse proxy, the outbound request to the OAuth Provider server must contain the X-Forwarded-Host request header, so that the server can identify the host value from the original request.
X-Forwarded-Proto header: In OAuth Provider scenarios that include a reverse proxy, the outbound request to the OAuth Provider server must contain the X-Forwarded-Proto request header, so that the server can identify the protocol from the original request.

Y

YAML: A data format. YAML 1.2 is a superset of JSON. YAML is not really a markup language since it is data-oriented rather than focusing on document markup. Whitespace indentation, rather than brackets, are used to denote structure. RAML, one of the API description document types supported by the API Platform, is based on YAML.

Z

zulu time: See Coordinated Universal Time (UTC).

Glossary of Terms

#

A

B

C

D

E

F

G

H

I

J

L

M

N

O

P

Q

R

S

T

U

V

W

X

Y

Z

Related Topics