One Identity Safeguard for Privileged Passwords 6.0.10 LTS

Releases use the following version designations:

Long Term Support (LTS) Releases: The first digit identifies the release and the second is a zero (for example, 6.0 LTS).
Maintenance LTS Releases: A third digit is added followed by LTS (for example, 6.0.6 LTS).
Feature Releases: The Feature Releases are two digits (for example, 6.6).

Customers choose between two paths for receiving releases: Long Term Support (LTS) Release or Feature Release. See the following table for details.

Table 10: Comparison of Long Term Support (LTS) Release and Feature Release
	Long Term Support (LTS) Release	Feature Release
Release frequency	Frequency: Typically, every 2 years Scope: Includes new features, resolved issues and security updates Versioning: The first digit identifies the LTS and the second digit is a 0 (for example, 6.0 LTS, 7.0 LTS, and so on).	Frequency: Typically, every 3 months Scope: Includes the latest features, resolved issues, and other updates, such as security patches for the OS Versioning: The first digit identifies the LTS and the second digit is a number identifying the Feature Release (for example, 6.6, 6.7, and so on).
Maintenance Release	Frequency:Typically, every 3 months during full support Scope: Includes critical resolved issues Versioning: A third digit designates the maintenance LTS Release (for example, 6.0.6 LTS).	Frequency:Only for highly critical issues Scope: Includes highly critical resolved issues Versioning: A third digit designates the maintenance Feature Release (for example, 6.6.1).
Support	Typically 3 years after the original publication date or until the next LTS is published (whichever date is later)	Typically 6 months after the original publication date or until the next feature or LTS Release is published (whichever date is later)

Release details can be found at Product Life Cycle.

CAUTION: Downgrading from the latest Feature Release, even to an LTS release, voids support for SPP.

One Identity strongly recommends always installing the latest revision of the release path you use (Long Term Support path or Feature Release path).

Moving between LTS and Feature Release versions

You can move from an LTS version (for example, 6.0.7 LTS) to the same feature version (6.7) and then patch to a later feature version. After that, you can patch from the minimum version for the patch, typically N-3. If you move from an LTS version to a feature version, you will receive a warning like the following which informs you that you will only be able to apply a Feature Release until the next LTS Release:

Warning: You are patching to a Feature Release from an LTS Release. If you apply this update, you will not be able to upgrade to a non-Feature Release until the next LTS major release version is available. See the Administration Guide for details.

You cannot move from a Feature Release to LTS Release. For example, you cannot move from 6.7 to 6.0.7 LTS. You have to keep upgrading with each new Feature Release until the next LTS Release version is published. For this example, you would wait until 7.0 LTS is available.

Patching

You can only patch from a major version. For example, if you have version 6.6 and want to patch to 7.7, you must patch to 7.0 LTS and then apply 7.7.

An LTS major version of Safeguard for Privileged Passwords (SPP) will work with the same LTS major version of Safeguard for Privileged Sessions (SPS). For the best experience, it is recommended you keep both their SPP and SPS in sync on the latest and supported version.

Using API and PowerShell tools

Using the API

Safeguard for Privileged Passwords (SPP) is built with an API-first design and uses a modernized API based on a REST architecture which allows other applications and systems. Every function is exposed through the API to enable quick and easy integration regardless of what want to do or which language your applications are written. There are even a few things that can only only be done via the Safeguard SPP API. The Safeguard for Privileged Passwords API tutorial is available on GitHub at: https://github.com/oneidentity/safeguard-api-tutorial.

Access the SPP API

Safeguard for Privileged Passwords has the following API categories:

Core: Most product functionality is found here. All cluster-wide operations: access request workflow, asset management, policy management, and so on.

https://<Appliance IP>/service/core/swagger/
Appliance: RAppliance-specific operations, such as setting IP address, maintenance, backups, support bundles, appliance management. https://<Appliance IP>/service/appliance/swagger/
Notification: Anonymous, unauthenticated operations. This service is available even when the appliance isn't fully online.

https://<Appliance IP>/service/notification/swagger/
Event: Specialized endpoint for connecting to SignalR for real-time events.

https://<Appliance IP>/event/notification/swagger/
a2a: Application integration specific operations. Fetching passwords, making access requests on behalf of users, and so on.

https://<Appliance IP>/a2a/notification/swagger/

You must use a bearer token to access most resources in the API. When using the Swagger web UI (as referenced in the URLs above), click the Authorize button at the top of each page and log in using the web UI. The Swagger web UI adds the bearer token to each API request automatically. However, if you are manually making the API request or writing your own application/script, perform the following two steps to obtain a bearer token.

You must first authenticate using the OAuth 2.0 Resource Owner Password Credentials or Client Credentials grant types. An example of the former is:

POST https://<ApplianceIP>/RSTS/oauth2/token

Host: <ApplianceIP>

Content-Type: application/json

Accept: application/json

{

"grant_type": "password",

"username": "<Username>",

"password": "<Password>",

"scope": "rsts:sts:primaryproviderid:local"

}

Where:
- grant_type is required and must be set to password.
- username is required and set to the user account you want to log in as.
- password is required and set to the password associated with the username.
- scope is required and set to one of the available identity provider's scope ID. The value shown in the example request, rsts:sts:primaryproviderid:local, is the default value available on all Safeguard for Privileged Passwords Appliances. User accounts that you create in Safeguard for Privileged Passwords directly (that is, not an Active Directory or LDAP account) will most likely have this scope value.
  
  NOTE: The list of identity providers is dynamic and their associated scope ID can only be obtained by making a request to:
  
  https://<ApplianceIP>/service/core/v2/AuthenticationProviders
  
  and parsing the returned JSON for the RstsProviderScope property.
If you wish to authenticate using a client certificate, you must use the OAuth 2.0 Client Credentials grant type in which your certificate is included as part of the SSL connection handshake and the Authorization HTTP header is ignored. Set the scope to rsts:sts:primaryproviderid:certificate or any other identity provider that supports client certificate authentication.

POST https://<ApplianceIP>/RSTS/oauth2/token

Host: <ApplianceIP>

Content-Type: application/json

Accept: application/json

{

"grant_type": "client_credentials",

"scope": "rsts:sts:primaryproviderid:certificate"

}
After successfully authenticating, your response will contain an access_token that must be exchanged for a user token to access the API.

POST https://<ApplianceIP>/service/core/v2/Token/LoginResponse

Host: <ApplianceIP>

Content-Type: application/json

Accept: application/json

{

"StsAccessToken": "<access_token from previous response>"

}

You should now have an authorization token to be used for all future API requests. The token is to be included in the HTTP Authorization header as a Bearer token like this:

Authorization: Bearer <UserToken value>

For example:

GET https://<ApplianceIP>/service/core/v2/Users/-2

Host: <ApplianceIP>

Accept: application/json

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1Ni...

NOTE: The token will expire in accordance to the Token Lifetime setting that is configured in Safeguard for Privileged Passwords (Settings | Safeguard Access | Login Control) at the time the token was issued.

Customize the response using API query parameters

You can use the following API query parameters to customize the response returned from the API.

The following output parameters allow you to define the property names to be included and the property names to be used for sorting.

Table 11: API query filtering: Output
Output	Example	Description/Notes
fields	GET /Users?fields=FirstName,LastName	List of property names to be included in the output.
orderby	Get /AssetAccounts?orderby=-AssetName,Name	List of property names to be used to sort the output. Implies descending order.

The following paging parameters allow you to include an item count, the starting page, and the number of items per page.

Table 12: API query filtering: Paging
Paging	Example	Description/Notes
count	GET /Assets?count=true	Indicates, True or False, whether to return a single integer value representing the total number of items that match the given criteria.
page & limit	GET /DirectoryAccounts?page=3&limit=100	page defines which page (starting with 0) of data to return. limit defines the size of the page data.

The following operators can be used to filter the results.

Table 13: API query filtering: filter parameter
Operator	Example	Description/Notes
eq	GET /AssetAccounts?filter=Name eq 'George'	equal to
ne	GET /Users?filter=LastName ne 'Bailey'	not equal to
gt	GET /Assets?filter=Id gt 10	greater than
ge	GET /Assets?filter=Id ge 10	greater than or equal to
lt	GET /Assets?filter=Id lt 10	less than
le	GET /Assets?filter=Id le 10	less than or equal to
and	GET /UserGroups?filter=(Id eq 1) and (Name eq 'Angels')	both operands return true
or	GET /UserGroups?filter=(Id eq 1) or (Name eq 'Bedford')	at least one operand returns true
not	GET /UserGroups?filter=(Id eq 1) and not (Name eq 'Potters')	narrows the search by excluding the "not" value from the results
contains	GET /Users?filter=Description contains 'greedy'	contains the word or phrase
q	GET /Users?q=bob	q can be used to search across text properties; means "contains" for all relevant properties.
in	GET /Users?filter=UserName in [ 'bob', 'sally', 'frank']	property values in a predefined set

When using the filter parameter, you can use parenthesis () to group logical expressions. For example, GET/Users?filter=(FirstName eq 'Jane' and LastName eq 'Smith') and not Disabled

When using the filter parameter, use the backward slash character (\) to escape quotes in strings. For example: Get/Users?filter=UserName contains '\''

One Identity Safeguard for Privileged Passwords 6.0.10 LTS - Administration Guide

Long Term Support (LTS) and Feature Releases

Using API and PowerShell tools

Using the API

Access the SPP API

Customize the response using API query parameters

Seleccione su producto:

Con el fin de ofrecerle un mejor servicio, complete el campo Motivo del chat:

Soluciones recomendadas para su problema

One Identity Safeguard for Privileged Passwords 6.0.10 LTS - Administration Guide

Long Term Support (LTS) and Feature Releases

Using API and PowerShell tools

Using the API

Access the SPP API

Customize the response using API query parameters