go to post Marvin Tener · Feb 21, 2018 Why do you need EnsLib.EDI.XML.Document? If you already have persistent classes, then you can use the persistent classes in many places where EnsLib.EDI.XML.Document can be used.
go to post Marvin Tener · Feb 8, 2018 Consider the flow of the access token:1. Client requests the access token.2. authorization server authenticates user and issues token3. client receives token -- IsAuthorized will now return 1 in the same CSP session4. client uses access token in Authorization header to authorize to resource server.5. The resource server knows nothing about the access token at this point. In order to validate the access token, the resource server either needs to check signatures (%SYS.OAuth2.Validation:ValidateJWT) or contact the authorization server (%SYS.OAuth2.AccessToken methods GetUserinfo or GetIntrospection). Exactly which method to use depends on how the authorization server is configured. The standards do not specify in detail. You need to contact the authorization server support folks.
go to post Marvin Tener · Jan 18, 2018 If you are generating access tokens, then you are probably on the server where the access tokens are stored in OAuth2.Server.AccessToken. OAuth2.AccessToken is where the access tokens are stored on the client. Both of these tables must be accessed from the %SYS namespace and privileges to access CACHESYS database are required.
go to post Marvin Tener · Dec 6, 2017 There is not enough detail in the question for me to be able to comment. I suggest that a call to support would be a good next step.
go to post Marvin Tener · Nov 8, 2017 There is no simple answer. There are a number of choices depending on how you handle users and your security concerns.First let me point you to the documentation at http://localhost:57774/csp/docbook/DocBook.UI.Page.cls?KEY=GOAUTHI'll mention two approaches:1. In the authorization server authentication callback routine, you can setup a property which will later be included in the JWT which acts as the access token. This property would specify the access rights. In this case, the JWT must be signed.2. On the client machine Cache security roles may be associated with the users which control their access rights. Then ZAUTHENTICATE may be used to log in the appropriate user based on the user associated with the access token.Their are lots of possible variation here. I suggest a read of the documentation and some experimentation. At that point if all is not clear, a call to support to talk through the options in your specific situation would be the next step.
go to post Marvin Tener · Jun 6, 2017 I thought about use of RFC 7523 a bit more and realized that in many situations it is appropriate to use the client credentials grant type from RFC6749 with the request authenticated using a JWT per RFC 7523. This usage is supported in 2017.1 and will give you many of the security attributes of JWT grant type.
go to post Marvin Tener · May 30, 2017 RFC 7523 specifies the use of a JWT both as an authentication mechanism for a client and as a grant type to obtain an access token. Cache supports the use of a JWT for client authentication in 2017.1. There are currently no plans to support the JWT grant type for obtaining an access token. This is a reasonable enhancement request.. I suggest that you make the request through the WRC including more background on your intended use. Then priority can be set.If you decide to add this support yourself, you should change OAuth2.REST to send the token endpoint request to your new class instead of OAuth2.Server.Token. The method in your new class can check for JWT case and process it or otherwise forward to OAuth2.Server.Token:Process. The OAuth2.Server.Token: CheckJWTAuthorization method has code which might help you learn how to handle JWT. Of course, the usual caveats apply to this approach.
