Recommended practice for asp.net/c# application logins?

(0) Share

Report

Posted on by Community Member

We have quite a few external (asp.net/c#) applications(10+) connecting to AX. Some are public facing, some internal.

Since each login requires a license, we'd like to limit the login accounts.

I'm thinking:

1. Create a public facing account and an internal account (both are not sys admin accounts, and grant only what's required by these applications)

2. Encrypt the web.config login

My concern is that, if we create a non sys admin account, it may be challenging to manage the account (update rights for every new application we build) and also makes development more difficult. (So much easier to have a sys admin account and develop and deploy).

In writing this, this makes me think.. use a sys admin account for development, but for production, use limited access accounts -- one for public and one internal facing applications.

What security measure do you recommend? What do you actually practice? Would love to hear your thoughts/recommendations.

Thanks in advance!

*This post is locked for comments

I have the same question (0)

All responses (14)

Answers (2)

Martin Dráb 237,912 Most Valuable Professional on at

Like (0)

Report

It seems that you talk about two separate topics: licensing and security.

What exactly is the problem about licensing? You say that "each login requires a license", but in fact each named user requires a license (unless you use device CALs). Therefore if somebody shouldn't access AX, don't give him access. If he need access, he needs a license (unless he's considered an external user, who don't need CAL).

If you believe that giving several users access through a single intermediate account reduces the number of licenses you need, please read what your EULA says about multiplexing.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Microsoft restricts one login per application? I thought multiple applications can use one login? We are not using one login solely to multiplex, the user already has access to AX, but the application needs login to access AX as well.

Was this reply helpful? Yes No
Martin Dráb 237,912 Most Valuable Professional on at

Like (0)

Report

I'm sorry, but I don't know what you mean by "restricting one login per application" and "multiple application can use one login". I didn't say anything like that.

First of all, what's you definition of "login"? A named user? A user session? Something else?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
When an application accesses AIF via .net/c#, it needs a login:

RemovalService.TransClient Client = new RemovalService.TransClient(); RemovalService.CallContext clientCC = new RemovalService.CallContext(); Client.ClientCredentials.Windows.ClientCredential.Domain = "domain.com"; Client.ClientCredentials.Windows.ClientCredential.UserName = "username"; Client.ClientCredentials.Windows.ClientCredential.Password = "password"; clientCC.Company = ConfigurationManager.AppSettings["Company"];

This is the login I was talking about, sorry for the confusion.

Was this reply helpful? Yes No
Verified answer

Vilmos Kintera 46,149 on at

Like (0)

Report

To answer your question, in practice we have created separate accounts for each AIF inbound port that we would like to expose. Those users are set as Trusted intermediary users on the inbound port, so noone else could consume it, only the intended audience. Those are our API users, exchanging information between AX and our web site / drivers' delivery application / inventory counting devices etc. Each has its' own license obviously for the previously mentioned reasons. That is only used to establish connection with AX from the API, after which we use runAs() to impersonate specific users and their security access to carry out tasks, like raise a sales order. Those web users are of User type Claims-based, because they do not need interactive logins within the AX client.

I hope the above scenario sheds some more light on what can and should you do.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
**UPDATE: below is not a solution **

For future visitors, what that means is use a non AD account.

1. Create a "Claims" user in AX

2. Add the user as a trusted intermediary for the inbound port

3. Apply the related service operation

4. Activate the inbound port

5. Your .net/c# code login should look like so:

Client.ClientCredentials.UserName.UserName = "Username";

(note there's no .windows., password, and and no domain needed in the code)

Was this reply helpful? Yes No
Vilmos Kintera 46,149 on at

Like (0)

Report

Claims users are also domain users, but we use a separate domain for them.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I've just tested the claims user account on a test server and AX rejected the account, it will only work with an AX sys admin account it seems. (apparently the app running locally was using my windows login to get to the service) I've rejected my answer above.

Still not sure how to get a claims user account working with the app and AX.. I've added the claims user as a trusted intermediary as well.

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (0)

Report

You are not doing it like I said. You need a valid AX user account (we call it API account), that will act as your trusted intermediary and can establish a connection to AX and is NOT a claims user (referred as calling user in the Documentation).

When you do it from C#, you can provide additional details in the "context", like which company do you want to connect to AND under what user account's credentials (claims user, just needs correct security access to perform the task, no direct interaction with the client, just the AOS) do you want to carry out your task. That is the bit which you are confused about I believe.

technet.microsoft.com/.../hh582244.aspx

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Can you provide the c# login code? I tried the link you've provided including variations of:

1.

holdClient.ClientCredentials.Windows.ClientCredential.Domain = ConfigurationManager.AppSettings["Domain"]; holdClient.ClientCredentials.Windows.ClientCredential.UserName = ConfigurationManager.AppSettings["UserName"]; holdClient.ClientCredentials.Windows.ClientCredential.Password = ConfigurationManager.AppSettings["Password"];

2.

holdClient.ClientCredentials.UserName.UserName = ConfigurationManager.AppSettings["UserName"]; holdClient.ClientCredentials.UserName.Password = ConfigurationManager.AppSettings["Password"];

3.

holdCC.Company = ConfigurationManager.AppSettings["Company"]; holdCC.LogonAsUser = ConfigurationManager.AppSettings["LogonAsUser"];

But it's not working for some reason.

Was this reply helpful? Yes No