Good question - it looks like the VS Code plugins only support password authentication for now. I'd encourage opening an issue against the InterSystems Server Manager GitHub project if you have a need for it. In theory this would be possible with some implementation work on the VS Code plugin. You would also need to enable delegated authentication on the /api/atelier web application in IRIS with a custom ZAUTHENTICATE routine to support OAuth.

Hi Joseph, I agree on using Client Credentials for this use case. As far as I know this is the only OAuth 2.0 grant type that authorizes server-to-server communication without the context of a user agent logging in. You can implement this in InterSystems IRIS by overriding the ValidateClient() method of the OAuth validation class: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic....

One thing to keep in mind is that by default anybody can register a new client with your authorization server by using the dynamic client registration endpoint. So the presence of a valid client isn't enough to authorize the API call. You will need some additional authorization logic.

The SSO system we use for this Developer Community has a "forgot password" implementation. Unfortunately it is down right now, but under normal circumstances  you would be able to try it out here: https://login.intersystems.com/login/SSO.UI.PasswordReset.cls

It works as follows:

• The user enters their email address into a form. They are then taken to another form with an input for a token.
• If the email address exists in the system, they are sent an email with a secure random token to input. Otherwise they are sent an email with instructions on how to register for an account.
• Once the user inputs the token from their email to the page, they are taken to another form to set their new password.

It's important to avoid user enumeration by not revealing in the UI whether or not a user with the provided username or email address exists in the system. You should also hash the password reset tokens before storing them in a database, give them a short lifetime before they expire, and invalidate the token after it's used once.

I highly recommend OWASP for more resources on how to do this securely: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_She...

Here are a couple of ways to avoid <STORE> errors by increasing the per-process memory available to IRIS processes:

• Increase the 'bbsiz' parameter, either by editing the CPF file or in the System Management Portal under System Administration > Configuration > System Configuration > Memory and Startup.
• In code in the specific process throwing the <STORE> error, set the $zstorage special variable to increase the memory available to that process.

Hello Martin,

Using "DROP COLUMN" deletes the property from the class definition and modifies the storage definition by removing the property name. The storage definition will still have a "Value" item for the data, but it no longer includes the name of the property.

If you have the class definition in source control, the easiest way to truly delete the data is to revert to the previous version. Then you can run DROP COLUMN again with the %DELDATA option to remove the column and delete the data.

If this is not possible, I would look at the storage definition and find the empty slot in the storage definition. The "name" property on that slot will give you the storage index. You could then iterate through the global where the data is stored and do something like set $list(value, name) = "" to delete the data. I would recommend contacting Support before doing this to see if they have better suggestions.

Hi Neil,

Using OAuth2 in a mirrored environment would require some additional scripting to keep the configuration in sync between mirror members, since as you note it's stored in %SYS.

The Server Configuration on the auth server won't be changing much over time so I'd recommend writing an installation script that sets up all relevant configuration. Below are some snippets from an installation class I'm using on a Caché authorization server:

ClassMethod CreateServerConfiguration(pOrigNamespace As %String = "%SYS", Output interval As %Integer, Output server) As %Status
{
    Set server = ##class(OAuth2.Server.Configuration).Open(.tSC)
    If $IsObject(server) {
        Set tSC = server.Delete()
        If $$$ISERR(tSC) Quit tSC
    }

    Set interval = 3600

    Set server = ##class(OAuth2.Server.Configuration).%New()
    Set server.Description = "Single Sign-On"
    Set issuer = ##class(OAuth2.Endpoint).%New()
    Set issuer.Host = ..#IssuerHost
    Set issuer.Prefix = ..#IssuerPrefix
    Set server.IssuerEndpoint = issuer

    Set scopes = ##class(%ArrayOfDataTypes).%New()
    Do scopes.SetAt("OpenID Connect","openid")
    Do scopes.SetAt("E-mail Address","email")
    Do scopes.SetAt("User Profile","profile")
    // Add whatever other custom scopes you need
    Set server.SupportedScopes = scopes

    Set server.AllowUnsupportedScope = 0
    Set server.SupportedGrantTypes = "APCI"
    Set server.ReturnRefreshToken = ""
    Set server.AudRequired = 0

    Set server.CustomizationRoles = "%DB_CACHESYS,%Manager"
    Set server.CustomizationNamespace = pOrigNamespace
    Set server.AuthenticateClass = ..#CustomAuthenticateClassName
    Set server.ValidateUserClass = ..#CustomValidateClassName
    Set server.GenerateTokenClass = "%OAuth2.Server.JWT"

    Set server.AccessTokenInterval = interval
    Set server.RefreshTokenInterval = 3*interval
    Set server.AuthorizationCodeInterval = 120
    Set server.ServerCredentials = ..#ServerX509Name
    Set server.SigningAlgorithm = "RS512"
    Set server.KeyAlgorithm = ""
    Set server.EncryptionAlgorithm = ""
    Set server.SSLConfiguration = ..#SSLConfig

    Quit server.Save()
}

ClassMethod CreateServerDefinition(Output server) As %Status
{
    Set tIssuer = ..#EndpointRoot

    Set server = ##class(OAuth2.ServerDefinition).%OpenId("singleton")
    Set:'$IsObject(server) server = ##class(OAuth2.ServerDefinition).%New()
    Set server.IssuerEndpoint = tIssuer
    Set server.AuthorizationEndpoint = tIssuer_"/authorize"
    Set server.TokenEndpoint = tIssuer_"/token"
    Set server.UserinfoEndpoint = tIssuer_"/userinfo"
    Set server.IntrospectionEndpoint = tIssuer_"/introspection"
    Set server.RevocationEndpoint = tIssuer_"/revocation"
    Set server.ServerCredentials = ..#ServerX509Name
    Quit server.%Save()
}

The client descriptions are likely to change over time as new clients are registered. I think to keep these in sync between mirror members you'll need to regularly export the relevant globals directly from the primary, transport them to the secondary, and import them into the %SYS namespace. Below are some methods that do the export and import:

ClassMethod ExportClientConfiguration(pDestFile As %String) As %Status
{
    new $namespace
    set $namespace = "%SYS"
    for type = "D","I" {
        set tList("OAuth2.Server.Client"_type_".GBL") = ""
        set tList("OAuth2.Client.Metadata"_type_".GBL") = ""
    }
    set tSC = ##class(%File).CreateDirectoryChain(##class(%File).GetDirectory(pDestFile))
    return:$$$ISERR(tSC) tSC
    return $System.OBJ.Export(.tList,pDestFile,,.errorlog)
}

ClassMethod ImportClientConfiguration(pSourceFile As %String) As %Status
{
    new $namespace
    set $namespace = "%SYS"
    return $System.OBJ.Load(.pSourceFile,,.errorlog)
}

You could use a task to do this regularly on a short schedule.

Hi Stephen,
I think you're on the right track by using custom claims for access control. This is what I've done in the past. Scopes in OAuth are intended to be granted by the user, which is not quite what you want here.

As far as I know there's no way to customize the token response. Your best option is to add the custom claims to the userinfo response. This means adding logic to your ValidateUser() method that will set the claim values and also add them to the list of user info claims.

Set tClaim = ##class(%OAuth2.Server.Claim).%New()
Do properties.UserinfoClaims.SetAt(tClaim,"MyCustomNamespace/MyCustomClaim")
Do properties.SetClaimValue("MyCustomNamespace/MyCustomClaim","something based on the user")

Then when the "resource server" part of your app validates the access token, you can call the userinfo endpoint to get this claim and determine the user's permissions.

$$$ThrowOnError(##class(%SYS.OAuth2.AccessToken).GetUserinfo(appName,accessToken,,.pUserInfo))
set myCustomClaim = pUserInfo."MyCustomNamespace/MyCustomClaim"

If you'd rather not make a separate call to userinfo each time, your other option is to add them to the body of the JWT. That would look similar in the ValidateUser() method, but with properties.JWTClaims instead of UserinfoClaims. Then your resource server can validate the signature on the JWT and get the claim from the token body using the ##class(%SYS.OAuth2.Validation).ValidateJWT() method. This is a little more complicated because you have to enforce that the JWT does have signing enabled (unfortunately the ValidateJWT() method will accept a token with no signature.)

I don't know of anything similar to Hibernate in Caché. If you want to encapsulate some data access logic inside of a class, it's helpful to define a class query that other objects can access through dynamic SQL.

More specific to your getByCode example, I use the index auto-generated methods a lot. For example in your dictionary table I would create a unique index on Code Index CodeIndex On Code [ Unique ]; and then use ##class(Whatever.Dictionary).CodeIndexOpen() to open the object I want.

For the first part of your question, here's a sample method that gets a bearer token from the request:

ClassMethod GetAccessTokenFromRequest(pRequest As %CSP.Request = {%request}) As %String
{
    Set accessToken=""
    Set authorizationHeader=pRequest.GetCgiEnv("HTTP_AUTHORIZATION")
    If $zcvt($piece(authorizationHeader," ",1),"U")="BEARER" {
        If $length(authorizationHeader," ")=2 {
            Set accessToken=$piece(authorizationHeader," ",2)
        }
    }
    return accessToken
}

EDIT:
And here is a full sample of a REST handler that retrieves a bearer token and reuses it to make a request against another REST service.

Class API.DemoBearerToken Extends %CSP.REST
{

Parameter APIHOST = "localhost";

Parameter APIPORT = 52773;

Parameter APIPATH = "/some/other/path";

XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ]
{
<Routes>
<Route Url="/example" Method="GET" Call="example"/>
</Routes>
}

ClassMethod example()
{
    set accessToken = ..GetAccessTokenFromRequest(%request)
    set req = ##class(%Net.HttpRequest).%New()
    set req.Https = 1
    set req.SSLConfiguration = "some ssl config"
    set req.Server = ..#APIHOST
    set req.Port = ..#APIPORT
    set req.Authorization = "Bearer "_accessToken
    $$$ThrowOnError(req.Get(..#APIPATH))
    set %response.Status = req.HttpResponse.StatusCode
    set %response.ContentType = req.HttpResponse.ContentType
    if req.HttpResponse.StatusCode <= 400 { //if not an error response
        set jsonData = {}.%FromJSON(req.HttpResponse.Data)
        write jsonData.%ToJSON()
    }
    return $$$OK
}

ClassMethod GetAccessTokenFromRequest(pRequest As %CSP.Request = {%request}) As %String
{
    Set accessToken=""
    Set authorizationHeader=pRequest.GetCgiEnv("HTTP_AUTHORIZATION")
    If $zcvt($piece(authorizationHeader," ",1),"U")="BEARER" {
        If $length(authorizationHeader," ")=2 {
            Set accessToken=$piece(authorizationHeader," ",2)
        }
    }
    return accessToken
}

}

You can add table-level privileges on all tables in the namespace by running "GRANT Select ON * TO Test", where Test is the name of the user or role. But if a new table is later added they won't automatically get access to it. I don't know of a way to do that with SQL privileges short of giving them %All.