Resources

Resources are things protected by IdentityServer, i.e., identity data of the end users or APIs. Every resource has a unique name that clients can use to specify which resource(s) they want to get access to.

Note: A client must have already been registered in the system to have access to particular resources.

Identity Resources

Identity resources are data like user ID, name, or email address of a user. In addition to the standard openid and profile resources, CRMLS OP defines a custom identity resource: CrmlsProfile, which contains member information required by CRMLS web applications.. The claims available in this resource are: (list of keys from key/value pairs)

  [
    "MemberLoginId",
    "MemberKeyNumeric",
    "UserLevel",
    "OriginatingSystemID",
    "OfficeMlsId",
    "OfficeKeyNumeric",
    "BrokerCode",
    "BrokerBranch",
    "MemberMlsSecurityClass",
    "MemberStatus",
    "MemberAOR",
    "OfficeAOR",
    "MemberEmail",
    "MemberFirstName",
    "MemberLastName",
    "MemberIsAssistantTo",
    "MemberStateLicense",
  ]

These claims (full key/value pairs) will be available when the client uses the scope parameter to request access to CrmlsProfile.

API Resources

An API resource is similar to an identity resource but instead of being user's profile data, the resource is an API that is protected by the IdentityServer. The client will still use the scope parameter to request access to the API. At this time, CRMLS OP defines these API resources: (scope = ...)

  • webapi - Currently a proxy interface to ODataApi
  • soc.api - An API for System of Choice related services.
  • synd.api - An API for Syndication options related services.

Access (client configuration to allow access) to appropriate resources must be prearranged with CRMLS.

Scope & Claims

From the client's perspective, the scope identifies the name or names of resources that it would need/want. For example, the parameter can be set to: "openid profile CrmlsProfile webapi soc.api synd.api". This would request access to all the resources; the standard identity resources and the custom identity resource, CrmlsProfile, as well as the three API resources. Although the client can request access for any resource; unless the client has already been configured within the system to be allowed access, that request would fail. In the example, if the client was not set to have access to any one of the scope entries, the entire request would fail.

As mentioned, the CrmlsProfile identity resource has the listed claims above. This is to allow visibility to the claims directly within the client application without a second round trip to the OP. Each of the other scopes (API resources) also have the same claims. The access_token (used as a reference token by the system) given to the API resource by the client (via Authentication header value "Bearer <access_token>") allows the API resource to obtain those claims from the OP while validating the client application's access.

Aside from scope, the respose_type is a parameter that the client will set depending on the particular flow and/or grant type. This parameter coincides with the grant type that was configured for the client within the system and what response types are enabled by the system. The discovery document (disco doc) lists CRMLS OP response types among other things (e.g., the issuer name, key material, supported scopes etc.).