Release highlights

We've just released Omada Identity Cloud update! What's new?

Omada Identity Governance improvements

With this release, Omada Identity now enables the renaming of accounts, streamlining governance processes and providing increased flexibility in managing user accounts.

Enhanced performance for Access Requests and Approvals

We have boosted performance for surveys. Now, approvals for surveys are completed faster.

Valid to Never expires

We've enhanced the Valid To functionality. Previously, when an identity had unlimited access to a resource, the Valid To field displayed 12/31/9999. We've now update it to read Never expires for clarity and usability.

With this change, when requesting access, you'll notice the new Never expires button option. Selecting this signifies that the identity will have unlimited access to the resource, streamlining the access management process and providing a more intuitive experience for users. This change will roll out for Access Approvals in a future cloud update.

New Omada Identity Graph API version 2.8

We've introduced a new version 2.8 in Omada Identity Graph API. This version includes a new query calculatedAssignments designed to retrieve all calculated assignments data associated with a specific system, based on the provided systemID. Additionally, we've enhanced the accessRequests/childAssignments. Now, it exposes additional properties from the RoPE calculated assignments. Previously, the only exposed fields were the identity, resource, and parent resource.

info

Refer to Omada Identity Graph API changelog to know more.

New UI and paging options for the Generic REST, OData, and SCIM systems

Generic REST, OData, and SCIM systems have new, redesigned Queries and mappings form. In the new UI, available options are grouped into tabs:

info

All collectors using generic REST, OData, and SCIM, which do not have customized JS files, are also affected.

We have also introduced the following new features:

• Adding headers to the query request

  • You can now specify headers at the query level, ensuring they are attached solely to requests for that specific query. This feature can be found in the Advanced tab:

    
    info

    Previously, custom headers could only be added in the Connection Details section, leading to them being included in all requests. Although still an option, you can continue to specify headers for all requests in the Connection Details section.

• Paging per query

  • You can now set, change, or disable paging at the query level. This option is available in the Paging tab:

    
    info

    This option offers the same paging options and types found in the Advanced form You still can specify paging for all requests in the Advanced form.

• Paging for nested requests

  • You can now change or disable paging type for nested requests:

    

OPS REST Connectors upgrade: JSON paths & request templates

We have enhanced the OPS REST and REST-based connectors with the following options:

• Introducing support for JSON paths property names, denoted by $. (dollar and dot), such as $.name, for example:

    <properties>
    <property name="$.added[0].loginId" />
    <property name="$.added[0].roles" multiValued="true" />
    <property name="$.added[0].sampleArray" multiValued="true" />
  </properties>

  • JSON path properties now support updating field values in the request. This includes both plain text and nested JSON structures. When a JSON value is provided, the connector constructs the entire structure in the specified location.

    note

    You can combine existing properties with JSON path properties to enhance flexibility. JSON path properties are applied at the end, atop the prepared request. JSON path properties can only be used if the JSON already contains the field identified through the path. They cannot be used to create new fields, making this feature particularly valuable for reconciliation scenarios or when utilizing request templates object details.

• Possibility to use request templates

  • Now, JSON request templates can be defined per operation within object details. The convention for detail names is {Operation}Request, for example, CreateRequest. These templates are stored in large data fields, enhancing customization and organization for each operation, for example:

        <object name="SampleUser">
    <objectDetails>
    <objectDetail name="CreateRequest" >
    <largeDataField>
    {
      "added":[
          {
            "organization":{
                "name":"my company",
                "type":"Company"
            },
            "roles":[
                {
                  "name":"Role 1"
                },
                {
                  "name":"Role 2"
                }
            ],
    "sampleArray":[],
            "loginId":"myLogin"      
          }
      ]
    }
    </largeDataField>
    </objectDetail>