I understand the mechanism of OIDC in Kogito with the help of process-usertasks-with-security-oidc-quarkus example.
However, I have a question about user information. In the given example, the approved field is filled by a Query string. Is there any way to get user information in Kogito? If it doesn't have that feature, can it reflect from header to service?
The integration with the security context inside the Kogito app is something that is on the radar, see https://issues.redhat.com/browse/KOGITO-6162. That would ignore the query string and use the authenticated user. Perhaps, for now, you could create your own endpoint to retrieve the authenticated information as needed and mimic the same API call that is done in the generated endpoint.
I figure out a temporary fix that problem with help of written Custom Service when using Kogito with Quarkus.
https://quarkus.io/guides/security-jwt
JWT Injection can call from the Service layer when used with Kogito.
It is also possible to propagate user identity to other workflow items with internally tagged process variables.
Related
What is the standard way of validating/authorizing that a user has access to a resource?
For example: a user can PUT comment/:id to update a comment, and I want to check if the user is allowed to.
Guards aren't ideal because they run before any validation and I need to access the comment id.
I've also tried a custom Param pipe but I'm struggling to access the request execution context from it to get the user.
Finally I could also just put the logic in the controller.
This seems like a pretty common use case so I was wondering: how does this typically get solved?
A common practice is to use OAuth 2 framework. Each valid user will have associated accesstoken that will be validated in the server before the user is allowed to access resource.
For NestJs Framework, you can checkout the official documentation on how to achieve this. https://docs.nestjs.com/security/authorization
I want to make an option such that I can issue 3rd part developers access to my data and to do so, similar to the following: https://docs.sharedcount.com/, I want to create a system wherein those developers are provided an API key for which the consumption count can be monitored
Came through Waterlock but does not look like it has this feature: http://waterlock.ninja/
Curious, what would be the best approach to implement API keywords for a Sail.js app?
Sails makes this incredibly easy by use of policies. When a user signs up, assign them an API key, and then create a policy that checks the params for a valid API key -- i.e. req.param('APIKey') -- and deny access if one is not found.
I am trying to use the new authentication system and I cannot find any decent articles/documentation to get what i want. Plenty of stuff out there explaining how the authentication process works out of the box but realistically you will need more.
First of all how do you control which database you store user information? I have read in many place that you can add a connection string. Ok great, but how do you get that connection string to be used by the authentication system?
And how would this work in a web farm, assuming user account information is split across databases with a little piece of logic which decides which database a user should login against?
I have used keystone extensively and it really isnt bad to implement. Its the authentication mechanism of Openstack. Check it out here http://docs.openstack.org/developer/keystone/
To answer your question users would first authenticate with it, receive a token, then they would present their token at any of your servers. If your data is split up, you can configure keystone to only allow access to certain areas of you backend via groups.
Changing the underlying database needs to steps. You have to add the connection string for the database you want to use for Identity. After this you have to change the base constructor call in your DB context to pass your new connection string to the base class (this is your missing step). An example for it is shown in this thread.
For your second question I don't have a good answer, because I haven't used Identity in a multiple DB servers scenario yet.
I have a Microsoft Dynamics CRM implementation (either 2010 or 2011 in not 100% sure). This CRM system needs to call our internal service framework services from plug ins.
In order to call the service framework we use an API with a login method that goes to an STS and gets a security token. This is per user to authenticate and get that users claims. The login call returns an IPrincipal object that we put on the Thread.CurrentPrincipal property and from then on we can call services with our framework and the user is authenticated for each call because of the principal on the executing thread.
In an asp.net website we usually log the user in and immediately go to the STS to get a token, then cache that token for the user in session because the login is not something we want to do every time we want to call a service.
How would I do this with a CRM plugin. Do I have access to a per user session store? I noticed IServiceProvider is passed in as a parameter, can I add services to this container and solve this problem in a service with a thread safe dictionary of some kind? I know very little about CRM development and Im even wondering if a plugin is the right way to do this?
The plugin is created and cleaned on a regular basis, you wouldn't be able to store anything for any period of time (or at least store it and rely on it being there).
You could potentially store this in a custom entity though if that is something that is possible?
e.g.
- Plugin is called for x event
Get CallingUser from Plugin
Search for MyCustomSTS entity for the User
See if Token exists and/or has expired
If you have the token - hooray
If not, run off and grab one
This may, of course, take longer than reauthenticating each time!
Is the token you are fetching for individual users or for the service account?
Ideally you should write your plugin to be stateless.
Write a Plug-In
For improved performance, Microsoft Dynamics CRM caches plug-in instances. The plug-in's Execute method should be written to be stateless because the constructor is not called for every invocation of the plug-in. Also, multiple system threads could execute the plug-in at the same time. All per invocation state information is stored in the context, so you should not use global variables or attempt to store any data in member variables for use during the next plug-in invocation unless that data was obtained from the configuration parameter provided to the constructor. Changes to a plug-ins registration will cause the plug-in to be re-initialized.
If you are fetching a token for individual users you could save that in CRM somewhere but that approach has a number of problems as glosrob suggests. In this case its probably just best to authenticate every time.
If its for the service account, you could go against the recommendations of Microsoft and cache the token in memory. Logically as long as your write your code to be happy with randomly loosing and having to reacquire its token you should be okay.
I agree with people who says that each time authentication is better solution, but if you need storage for tokens, you can create custom CRM entity and write logic which will work with tokens stored in CRM from plugins.
I am trying to validate a SAML token that was created by our WIF-based custom STS inside a REST web service.
There are a couple of functions to do validation. One is SecurityTokenHandlerCollection.ValidateToken() and another is SamlSecurityTokenAuthenticator.ValidateToken().
Unfortunately the online Microsoft MSDN help for these classes and functions is worthless and does not describe at all what it is these functions are doing.
What are these functions validating and how are they doing it? What are the differences between them? Are they automatically looking up the certificate in the Windows Certificate Store to check the signature of the token, and validating the encrypted credentials object? Because I don't pass a certificate name in anywhere. Or are there other manual operations I need to do myself to validate the token?
I realize one returns a ClaimsIdentityCollection and the other returns a collection of IAuthorizationPolicy objects. But is that the only difference? I can't tell.
I can find plenty of information out on the web about the STS and claims and even validating claims, which I am doing successfully, but I can hardly find any information on validating the token itself to make sure it is one I created.
In most cases you don't need to worry about the token validation details. All this is taken care for you by WIF.
But if you really want to know, the best source of information is Vittorio's book: http://www.amazon.com/Programming-Windows%C2%AE-Identity-Foundation-Dev/dp/0735627185
There are some details here: http://msdn.microsoft.com/en-us/library/ff359114.aspx
Another good way of learning is by looking at the extensions built to handle non-SAML tokens (e.g SWT). Download the samples here and look for the REST services.