Looking to create a completely external portal using only HTML5, JS, and CSS to show CRM 2011 data. It does not look like I can use REST or SOAP because they cannot authenticate externally. Does anyone know how I would do this?
Thanks!
To do this, your OrganizationData.svc service would need to be externally accessible, and it would need to function without authentication (or, your authentication would need to happen within your javascript - where the end user would be able to read your source code). Either way is not a wise idea, since all of your data would be visible to the world!
If you are only dealing with internal authenticated users, read up on the oDATA endpoint.
If you want to deal with external and/or unauthenticated users, you'll need to find another way to do this that does all of the data filtering & authorization control you need.
I think we normally achieve this using a intermediary integration service. You could have a service which has access to the Org service through conventional CRM authentication, and which provides a number of methods which can be called anonymously (or by custom security) by client code.
For example, a web page calls the 'int' service's 'getContact' method, passing an email address of the user. The 'int' service validates the user's email address and then retrieves the required data from CRM's org service, using credentials stored in a config file (a CRM user with sufficient permissions to serve the 'int' service's methods). The 'int' service then parses the data and returns it to the client code - which has no knowledge of CRM's existence - perhaps as JSON for usability.
Related
I have a google apps script that has an API key set as a property (getScriptProperties()). The script is attached to a spreadsheet. Will users of the spreadsheet conceivably have access to the API key? Would this be different if said property were contained in a library the script invoked?
Will users of the spreadsheet conceivably have access to the API key?
Yes, if stored in Script/Document properties. User properties are also accessible, if the user has installed a trigger.
Would this be different if said property were contained in a library the script invoked?
Kind of. As written in resource scoping, Script properties are not shared, i.e., library has it's own instance of script properties. Although it's not shared automatically, you should be careful not to code in such a way to give access to the end users(i.e., The actual fetch should happen in the library. Secrets should never reach user code). It may still be possible to access the tokens through debugger, overriding methods(see link below). User properties are shared.
Related:
Securely Storing API Secrets used in Google Apps Script - Published Library
What is the appropriate way to manage API secrets within a Google Apps script?
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.
Is it possible to secure SharePoint rest APIs?
I have a SharePoint portal that allows users to create accounts an get access to the portal.
The portal uses SharePoint client object model, if any of the users try to access let's say getuserbyid method or retrieving items for lists and changes the ID value, he will be able to retrieve information for other users on the portal.
So it is possible or is their any way to restrict access to the rest APIs outside the portal itself? Because with manipulation using Fiddler or burp suite the request can be replayed with different information or values.
The operations performed by the Client Side Object Model respect the SharePoint site permissions in the SharePoint site you are interacting with. You need to set/customize the site permissions such that you get the results that you want.
I have just an idea for now to develop an application based on foursquare API.
I checked in the website that a creation of an application inside the foursquare is needed to access the api functions.
There some form fields in the application creation that cannot be filled by me as I don't have an application yet, like web address home page, privacy police page, etc.
I want to perform some tests for a certain time and then choose if I'll proceed with the application development or not.
For now I just need access for the venue stats function. Do you know if it's possible to have access to this function without have an official application?
Regards,
Rodrigo Lima
You need to create an application in order to get an OAuth token, which you need to call venues/stats. In practice, during testing, the only real field that needs to be accurate is the redirect URI, which you'll need for OAuth. The others can take dummy values for now, so long as you go and change them before you publish.
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.