I have written a plugin in dynamics CRM. This plugin accesses a few Web API 2 methods that are deployed in Azure cloud (via HTTPS). The plug-in is triggered when a contact data in the CRM changes. Many CRM account holders will update the contact data.
I am going to hard code a 'secret key' (a one time generated Guid) in the plug-in and send this key every time I access the web api methods. I'll validate this guid in the web api methods to prevent un-authorized access.
I do not like to store the secret key (guid) in the source code.
Questions
What are my alternatives if do not want to 'hard code' the secret key?
What are the security flaws in this approach?
Note
In general, all my Web APIs are authenticated by a custom authentication web api filter, but the Web APIs that are accessed from the plugin are not part of the custom authentication.
CRM version is 2013
As the previous answers states, the first option is to store your information in a configuration custom entity that you can retrieve from your plugin. Those records are going to be protected by the CRM security model, so if your plugin is running in the calling user context you will need to make sure that the users have privileges to read that information (not really a good idea) or change the plugin to be executed under an admin user context.
Another option is to use Secure/Unsecure Configuration:
Those are two (string) parameters that you can configure within the step and you will be able to read them from the plugin. I would say that the secure configuration fits your requirement but give it a look. You can also easily find how to implement it (example).
The third and last option that I can think of, is to create an XML WebResource and read it from the plugin. Again, you will need to make sure that the user context under the plugin is running has access to it.
I don't think this approach will ever be secure.
It's possible to extract the plugin assembly from CRM. Someone could then disassemble the assembly and find the Guid. Effectively your password is stored in plain text.
At the very least you could store the user name/password/secret key in a CRM record. The CRM record can then be protected with CRM security.
You are probably better off implementing the authentication 'normally'.
Related
I'm wondering if it is somehow possible to display a private report if we don't have access to the account or company's Data Studio environment? Using the Google API would be ideal.
The reason why we need an API is because the reports need to be displayed on a distributed network of displays where user interaction is not possible. They are all separated from each other and run on their own browser instance. Setting the reports public to embed them is not an option due to sensitive data being exposed to the internet. Embedding is fine but we need some way of accessing the customers data without user interaction, i.e. via access tokens or something. If the user authenticates to our app beforehand and that allows us to then use their access token inside of the embed iframe would be fine too.
As far as I can tell I cannot display private reports through the official google-data-studio API. I did find another stackoverflow link that mentions something about community connectors. Would this still be a solution to our problem if we don't own the reports itself? We are just displaying the reports but do not have access to their Google Cloud environment nor their data sources.
Any help is appreciated.
This is not supported by Google Data Studio.
In short, if you can't make your report public, and you can't authenticate to view it, you're out of luck.
The link you provided is much more a hack than a feature. It suggests you to make your data public with a custom authentication mechanism developed in a Community Connector that requires a token as parameter.
This way, your report will be available to anyone, however, since your report requires the token to work (a kind of password), it won't show any data to unauthorized users (those who don't provide a valid token).
Although it is possible, I think it requires so much effort to make it work, and, of course, it requires that you change the connector of your report. So 'yes', you need to own the report to connect to your data through the suggested Community Connector.
I have an MVC application (.Net Framework 4.5) which is been there for the last three years and using Forms Authentication mechanism. This application provides different accounts like Personal, freebie, Enterprise etc. For an enterprise account, we are handling everything in the same application. I.e. Suppose an enterprise called “xyz” created an enterprise account with the application, then we are providing a custom URL like “https://application/xyz/login” and from the URL we are identifying that enterprise. I don’t know the exact reason why they implemented like this as I have seen applications that are having enterprise accounts are created as subdomains (e.g. https://xyz.okta.com). Now the client asked to integrate Okta into this application.
So I looked into Okta and found SAML is the right way to do and ends up in KentorIT Authservices. Initially, I was able to integrate this with a sample MVC application and the authentication part was working fine. With some basic idea about SSO, I have started integrating kentor authsevices into my application. The challenges I found in this implementation are:
1) For Enterprise accounts, Okta configuration settings are different for each enterprise and with my current application implementation, it is not possible to set it in from the web.config. So I have tried to set it from code and I was able to integrate those settings by replacing Configuration.Options.FromConfiguration;. I’m planning to store all configuration related things(Single sign-on URL, Audience URI,Identity Provider Issuer" etc.) in the database so that I can get the information whenever I wanted and I’m assuming that “Identity Provider Issuer Id is unique for each Okta account. In an IdP initiated flow, when the user tries to access the application it will redirect to AuthServices\Acs action method and from that, I’m trying to read the configuration settings. From the request is there any way I can identify from which Okta account call came(like Identity Provider Issuer)? Currently, I set the "Identity Provider Issuer" value (and I think which should be unique for okta account) to the Default RelayState field under General SAML settings tab and I was able to retrieve it from AuthServices\Acs action methods. Does it seem to be a good idea? Please advice.
2) The Enterprise accounts are limited based on the number of licenses (say 50). Suppose if the Enterprise Okta admin intentionally added 55 users all those users can successfully authenticate the application based on the default settings. Is there any way I can handle this scenario. Do I need to keep a record of the list of users that came under a particular enterprise account?
3) From the documents I understand that Kentor authentication service is only for authentication and authorization part has to be done from the application itself. The current application implementation consists of a custom authorization attribute which checks for user permissions that are stored in the database. That should be there as it is and we have to do the authorization based on database permissions. Right?
Expecting your valuable suggestions and please correct me if I'm wrong. Thanks in advance.
Don't use the RelayState for sensitive data unless you cryptographically sign it. It is not protected by any signature when using the POST binding, so the user may manipulate it. To get the issuing idp, check the issuer field of any claim generated by AuthServices instead.
Yes.
Yes, that's the whole idea with Kentor.AuthServies: To plug SAML2 authentication into the security model of .NET to allow you to use any current/traditional Authorization setup.
I have an ASP.NET 5 (RC1) application for which I am trying to set up authentication and authorization. However I am confused and overwhelmed by all the varying authentication and authorization information online in as it pertains to this platform. Much of it seems either hopelessly out of date or simply doesn't seem to apply in this particular usage scenario. Right now, I'm not even sure what the right 'terminology' to use for the question I am trying to ask, but I digress.
What I am trying to accomplish is a system whereby users are authenticated/authorized via Azure AD (B2C?), with additional user profile information stored in a database. However, the user context in the controllers is accessed in a consistent way using what I presume would be a custom ClaimsPrincipal/ClaimsIdentity? I would imagine this should be as simple as adding an 'authorize' attribute or something similar and accessing the ClaimsPrinciple.Current.Claims.
I have used ASP.NET Identity in the past, but many of the examples I have found aren't using that. Most are simply using the UseOpenIdConnectAuthentication middle-ware. I see that ASP.NET Identity is still available but I'm not sure it applies in this scenario. I also found a couple posts on here suggesting using a custom ClaimsIdentity to accomplish this, but I am having trouble finding useful up to date examples. BTW, I realize that much of this "profile" information can be stored as custom attributes in azure ad but the way some of the information is used within the application prohibits all of it from being in azure (i.e. EF linq joins and such).
Please, tell me if I am even close on some of this. I know this is a fairly new platform and the information is sparse, but certainly I'm not the only one asking these questions.
Just calling out an excellent article Identity management for multitenant applications in Microsoft Azure.
A lot of your questions are answered there.
e.g. you can augment the claim in the OWIN middleware AuthenticationValidated event.
ASP.NET Identity is claims-based in that the attributes are delivered as claims but authentication is on the DB, not via external IDP like Azure AD.
B2C is a special case in Azure AD - used for many (millions!) external users who can self-register and self-manage e.g. SSPR.
B2C uses a separate tenant to the normal Azure AD one and the users have no access to things like O365 or any SaaS applications.
So I have CRM Online and SharePoint Online as document storage. I have the list component installed and everything is working there. I have a plugin I have built which generates emails, and as part of the process, grabs documents from various SharePoint folders and attaches the to the email before sending.
To do this in a SharePoint online environment, I have to go out, grab a SAML token from MS's login STS service, pass the token to SharePoint, receive a couple of authentication cookies back, and pass those cookies along with any requests I make to SharePoint. All of this is working. The bad news is I have to have a username and password hardcoded in (or prompt the user). Is there any way from inside CRM Online to grab the current user's credentials and pass that to get the SAML token? I mean there has to be since CRM does it when you create the document libraries when you turn on Document Management, right?
I can't use the SharePoint dlls inside CRM Online plugins, it is security restricted. I cannot access the CredentialCache, security restricted. Hell, I even looked at trying to intercept the cookies somehow with Javascript, but it looks like they are HTTPOnly and pretty much inaccessible.
Tried putting in a Microsoft ticket and got some low level guy who immediately passed the buck and called it unsupported.
You can't get user's password in CRM. If you are developing a plugin, the plugin can run in the user context and the code will execute based on the logged in user. Therefore you don't need to pass any creds for adding a document in CRM.
Check out this url, it helps you understanding how impersonating works in CRM.
https://msdn.microsoft.com/en-us/library/gg309416.aspx
Hope this helps.
I'm trying to figure out how should I integrate facebook login system in my existing application through facebook c# sdk.
I have a web forms application and I'm authenticating users by standard Login control.
I'm using MembershipProvider, RoleProvider and ProfileProvider.
I'm thinking I should persist FacebookUniqueID and put it into relation with existing informations on my Membership Users table.
I'm wondering wich is a correct approach to this.
Considering I have a custom Profile Provider that uses a custom sql table, it would be fast to add a FacebookUniqueID property to my user profiles and use it in my login workflow:
Login through facebook;
retrieve facebookUniqueID;
retrieve userName for the user that
have this specific facebookUniqueID,
then
FormsAuthentication.SetAuthCookie(userName, bool);
What about providing an overload for the previous method taking facebookUniqueID as parameter?
Please let me know what do you think about this from any perspective and if anyone knows a simple working example
I think you are on the right track. We implement a similar solution (though we have rolled our own custom membership/role/profile etc and don't use the built in approach.)
You also will have to handle the situations that occur when a new user (without an existing account) logs into your site via Facebook.