go to post McLean Cozine · Apr 13, 2022 There's a $SYSTEM.Encryption.RSAGetLastError() function that might provide more insight into why validation is failing in this specific case. The code snippet seems correct, so my guess is that this is not the reason validation is failing. Could the signature have been made over more than just the string "hello"? Could the cert have a public key that doesn't correspond to the private key used to make the signature? It shouldn't be the case, but does it work if you have set isValid = $SYSTEM.Encryption.RSASHAVerify(256, tData, tSignature, tX509.Certificate,"","")? (Because the method does take 6 arguments, though the last two should be optional)
go to post McLean Cozine · Feb 17, 2022 As Alexander said, the Creating the Server Configuration Items Programmatically link should have the information you need. Note, in particular, the types of the properties. Looking at what you have here, the IssuerEndpoint and SupportedScopes properties are of the wrong type: IssuerEndpoint needs to be an OAuth2.Endpoint object and SupportedScopes is an array of strings so should be set withdo oauth2server.SupportedScopes.SetAt(<scope description>,"ikp-scope")
go to post McLean Cozine · Dec 7, 2021 Hi M C, Currently, you cannot add custom headers to a JWT. On top of this, the x5t header parameter (which, as I'm sure you're aware, is required for Microsoft Identity platform JWT assertions) is not added to JWTs in ObjectToJWT(). Unfortunately, this means that 2 of the 3 options Microsoft gives for the client credentials flow will not work. If you need the client credentials flow and can use the first case in that Microsoft page you linked to (access token request with a shared secret), that's probably your best bet. (Also, to circle back to your original question, while you do not need to set your production up as an OAuth client to use JWTToObject() and ObjectToJWT(), you should do so in this case because you are using it as an OAuth client.) Sorry to be the bearer of bad news, but I hope this helps,McLean
go to post McLean Cozine · Sep 13, 2021 Hi Michele, Access tokens are Persistent objects so they are already stored on the server. As an administrator of an Authorization Server, you can view all of the access tokens issued to a given user like any other Persistent object stored on the server. If all you want is, at any given time, to see what access tokens are issued to a given user you can query the OAuth2.Server.AccessToken SQL table for that information. However, if you are asking if the timing of saving an access token can be changed, you are out of luck. For all grant types other than Implicit (which is being deprecated), the actual access token can't be created until after the user logs in, so there is no way to store or present the access token as part of the login process because the access token does not yet exist at that point. I hope this helps,McLean
go to post McLean Cozine · Feb 18, 2021 Neil, I found this discussion on mirroring parts of the %SYS database: https://community.intersystems.com/post/how-sync-user-accounts-resources.... There are a few interesting ideas here that might be worth checking out. For instance, seeing if you can make an OAUTH database and map the contents of the OAuth client/server/etc. tables into it. Or seeing if you can create export and import methods for OAuth things. However, the fact that this is the most relevant discussion I could find seems to confirm that there's no accepted way to mirror parts of the %SYS database. The Server Migration Guide (https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=AMIG) has notes on exporting from the IRISSYS database, though, it seems to focus on security settings, tasks, and custom items, none of which might be particularly helpful in this case. That said, it might be worth toying around with. Sorry to have gotten your hopes up before, but hopefully some of this might help a little more. McLean
go to post McLean Cozine · Feb 17, 2021 Hi Neil, I come bearing bad news, which is that it looks like I was mistaken and the OAuth objects are all stored in the %SYS database after all. I'll have to look into this a little more because I have to imagine that OAuth can be used in a mirrored environment. Not that it's necessarily helpful if the mirroring doesn't get sorted out, but this is the link to the OAuth HealthShare documentation: https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI... I was talking about. I'll look into the mirroring question a bit more myself and see if I can find any better answers. McLean
go to post McLean Cozine · Feb 16, 2021 Hi Neil, You should be able to use OAuth 2.0 in a mirrored HealthShare environment just like you would in a non-mirrored one, I don't know of any difference in best practices. Assuming that you have set up your Mirror VIP properly the fact that you are using a virtual IP address shouldn't matter. Clients trying to connect to your server only need to know the VIP and HealthShare should take care of the rest. As for the failover question, all of the necessary components of OAuth 2.0 are stored in the HealthShare database (access tokens, client configurations and definitions, server configurations and definitions) and therefore should be mirrored across machines. This means that OAuth, once set up, should be good to go in case of a failover. Have you looked at Using OAuth 2.0 and OpenID Connect in the HealthShare docs? That chapter has instructions and some best practices for using OAuth with HealthShare that I think apply to mirrored and non-mirrored setups just the same. Hope this helps, McLean
