Skip to main content

Through our ongoing efforts to make the Authress Management Portal easier to use, nicer to use, prettier to use. We've introduced the following improvements.

User Explorer Icons​

Until now, when one of your users had a picture claim associated with their user identity, it would not show in the portal. Now all safe user icons will be automatically displayed.

User Explorer Icons

Profile pictures will be displayed if the images for the user are sourced from one of the following locations:

  • Google
  • Secure Gravatar
  • Slack Avatars
  • Authress identity pictures

There are more coming to this list. However, not all pictures will be automatically shown. This is because not all image hosting locations are secure, and if a malicious image is uploaded to that location, and isn't validated, showing it to you in the management portal creates an attack surface. For this reason, be careful of media platforms that allow users images to be shown to you without taking the necessary security precautions. If there is a source location you would like added to this list and we can verify that provider is taking the necessarily precautions with shared images, it will be added.

Access Record Resource Hints​

Access Records resources dropdown will now dynamically populated with suggested resources. This makes it easier to filter and find the resource URI that are looking for. It also helps to avoid potentially guessing when the resource isn't present.

Access Record Resource Hints

Resource Tags​

Just as environment were displayed before, now all Authress related resource tags will be visible in the portal as well.

Resource Tags

The Authress Access Analyzer is our way of giving you the advanced tools you need to answer the complex authorization question you might have.

Questions such as:

  • Does that user really have the correct permission to the resource?
  • What's that user's access right now?
  • What are all the resources the user has access to with this permission?

While these actions are at the forefront of Authress authorization checks and done usually via one of the Authress SDKs, getting answers to these questions directly in the Authress Management Portal, makes it so much easier.

This release includes two new features for the Access Analyzer.

Access Record Source​

When a user has access to a resource via an access record, the Access Analyzer now shows that linked access access record as well as the role that granted the access.

Linked Access Record information

Access Check History​

After each access check the Authress UI will now save and display these checks to make it easier to see what was just validated. This makes it possible to compare a list of authorization checks for anything that might not be working correctly.

Authorization check history

The Authress API endpoint for querying users /v1/users now accepts filtering by a tenantId. This enables custom user workflows based on your customer's accounts.

Your customers accounts can be grouped by an identifier known as a Tenant. A Tenant is a logical source of users for your application. Usually Tenants map one-to-one with your customers. Each of your customer accounts has users that log into your application. During the use of your application there may be a need to fetch all the users that also belong to that same customer account.

This can now be done by passing in the tenantId query parameter to the List Users endpoint.

Authress has automated away the Login configuration experience. Instead of having to built your own login screen, Authress supports a managed version for you to configure.

List Users API endpoint

Authress introduces Vanishing Keys. Vanishing Keys is an open source one time secret store to enable ease of secret transfer.

In most cases, secrets should be generated and stored by the creator of the secret. And where possible secrets should only be generated at runtime. For this solutions such as a Key Management Service exists.

However, this is not always possible, and we need to transfer ownership of a secret from one person to another.

More details about how the Vanishing Keys service works is available in the documentation, but the important part of this new Authress service is that it provides 100% client side encryption. The secret and secret passphrase never leave your browser unencrypted.

Creating a Secret​

Authress Vanishing Keys

Authress Vanishing Keys

How it works​

Authress Vanishing Keys

Authress has automated away the Login configuration experience. Instead of having to built your own login screen, Authress supports a managed version for you to configure.

Customized login box

The customized login screen is dynamically generated from account configuration. And allows further customization based on:

Standard Apps​

This is purely add-on functionality. Login for regular apps will continue the same as it has been, and your users will not see any difference. You can continue to directly overwrite the default Authress Login Box by passing the connectionId to loginClient.authenticate() call in the Authress Login SDK.

Platform Extensions​

For platform extensions, the default login experience has just been upgraded. If you didn't already have a customized login screen for third party extensions, the Authress managed version will automatically be provided without any additional configuration necessary on your side.

Authress now supports automated resource creation and configuration via Terraform.

Terraform provider for Authress

CI/CD Guides​

To support a more streamlined integration, Authress offers guides for Terraform as well as OIDC CI/CD guides for GitHub and GitLab. These CI/CD guides make managing Authress resources securely a simple matter without needing to be a security expert.

Quick setup guide for OIDC​

Additionally, Authress has released a quick setup guide for OIDC. The guide steps through the flow to secure a CI/CD pipeline automatically without needing to create an Authress service client. Instead, Authress supports the dynamic credentials that are generated by your CI/CD platform to log into Authress. Follow the relevant OIDC CI/CD for more details.

To enable increased security and reliability Authress offers the ability to set a Custom Domain for your account. A Custom Domain enables your services to interact with Authress on a domain that you control. Any domain you own can be set. That domain will be used for:

  • API calls to Authress from the SDKs you configure
  • JWTs Authentication that Authress generates for your services

Historically, only one domain could be configured per account. In most cases you will only want a single domain, since it can create complex additional scenarios to deal with. For example, if valid tokens created by Authress now can be signed with either of two possible domains, now your services need to deal with two possible JWT Issuers.

In some cases this is intentional though, or perhaps you are in the process of rebranding, and need more than one domain to be active at the same time. Because of that, Authress now offers support for multiple simultaneous domains.

Enable an Authress custom domain

Starting today multiple wildcard support is globally available. Requests to check authorization can include multiple ✶ anywhere in the resourceUri. Requests to the authorization check endpoint accept resourceUris for example:

  • In multiple places in the hierarchy: /resources/✶/nested-resource/✶
  • Present in requests for namespaces: namespace:✶/resources/lower-namespace:✶/nested-resource

API update: Resource List​

To further support this functionality the List user resources endpoint now accepts a new parameter Collection Configuration that explicitly enables the type of collection result a request expects.

The original functionality was to only return immediate top level resource matches to a request. This functionality remains the default. When searching for /resources/✶, the result will be a list of matching resources: [ 'resources/001', 'resources/002', ... ].

The endpoint now supports INCLUDE_NESTED.

API Resource List

Specifying this value cases deeply nested resources to also be returned. A request for /resources/✶, will return: [ 'resources/001', 'resources/002/sub-resource/✶', 'resources/003/sub-resource/003' ]. And additionally requests can include multiple wildcards: /resources/✶/sub-resources/✶, will filter by both resources and sub-resources.

info

What's great about this new functionality is that users with access to ✶ will also successfully return results. Having access to all resources templates the result. ✶, with a search for /resources/✶ will return [ '/resources/✶' ], making it easier to utilize these results without adding extra filtering logic.

Starting today, the statements in an access record, can now additionally specify both users and groups.

User based access records​

Historically, users and groups were only available as properties of the access record, which meant all statements applied to all users and all groups. This made it easy to support having one group of users with many statements. Additionally, access records could be directly associated with a user so that it was clear that changes to an access meant changes for that particular user.

To change a user's permissions, it was as simple as looking up the access record with the same ID as the user:

Fetch an Authress access record
const record = await authressClient.records.getRecord(userId);

And then making necessary changes to that record.

Resource based access records​

However, when multiple users each needed different access to the same resource, multiple access records would need to be configured. One for each set of permissions. This was because all statements in the access record applied to all users in the record. To have different permissions, separate records would be created, each with the separate set of users.

Now, access records can directly specify which statements should be applied to which users.

Instead of listing the users at the record level:

Access record users

Toggle the Enable statement level user assignment switch:

Enable statement level user assignment switch

And then enter the users in the statement section of the record. Each statement can have separate users:

Access record statement user selection

A new menu item is available in Authress to quickly create new commonly used flows. These flows are knows as Quick Setup Guides and will be populated frequently used options.

Authress quick setup menu item

See the Quick setup guides.

Quick setup guide for authentication​

The first released setup guide is for authentication. The guide steps through the flow to create an application, a connection to an OAuth identity provider, and provides example UI code to directly log a user in.

On the completion of the flow you can already start managing user identities.