I have the below problem I try to solve:
There is an MVC web application (AppA) in domain DomA that is configured to use a CUSTOM STS for authentication/authorization.
On the other hand we have a CRM installation in another domain, the MyCRM domain, that is configured to use ADFS (ADFS is in the same domain as the CRM).
What we want to achieve is the AppA to be able to POST data to the Dynamics CRM Web API but we don’t want the users of AppA to re-enter credentials or have any other kind of interaction regarding authentication/authorization with ADFS.
The AppA should be able to POST data from both Javascript (client side) and the backend (MVC controller)
How could we achieve the above?
What kind of Trust should we establish between the Custom STS of DomA domain and the ADFS of MyCRM domain?
You don't need federated identity for back-end (server-to-server) connections. You might want to use Impersonation which permits you to setup a user account that can act on behalf of another user in the system.
Related
I'm working on a web application that uses OpenId authentication. Let's assume that the application essentially serves to store metadata and its associated files (docx, pdf). The Web Application is for internal use and is not exposed to public network, only users of the organization have access.
Recently, a requirement has arisen to be able to share files with users external to the organization. External users will use a PORTAL (third-party application) which, through a URL generated by the Web Application that points to the PORTAL, will have access to the file. This PORTAL uses OpenId authentication and invokes a Web Application API to retrieve the file.
Initially, the proposed solution was:
Web Application - Send EMAIL to the external user and create a user in Keycloak with Email to authenticate later on the PORTAL (Is this really necessary?! Biggest doubt).
The external user accesses the PORTAL with the URL received and authenticates with the user created by the Web Application on Keycloak.
Once authenticated on PORTAL, a WebApplication API is invoked to obtain the file.
The main question is whether the Web Application should manage the creation/editing/deleting of external users on Keycloak. Does the Web Application need to create users in Keycloak? Is there another way to accomplish this without compromising security?
Thanks in advance.
To share a file with restricted access, there are two approaches:
Open access with signed links: Create a signed URL using a web API and share it with external users. The link can be a static URL with an encrypted key, or a JWT signed token in base64 form generated by the web API. When the portal receives a request, it checks the validity of the token, retrieves the file location from the token, and allows access.
Email-restricted access: If you want to guarantee access only to the person with email xxx#abc.com, you'll need to use a challenge, which is typically a login. You can either create users on the fly after login (if the external users come from a partner with OIDC capability), or pre-create the users if this is not the case.
Note: You cannot rely solely on a URL with an email claim as proof of access, as the link may have been forwarded to someone else.
I am trying to follow this post to let my web application authenticate with ADFS before calling CRM.
Apache CXF client for claims-mode xRM (Microsoft Dynamics CRM 2011)?
I am not sure what kind of user I should create in ADFS in order to access CRM. What is the proper permission or user roles?
Also UserNameWSTrustBinding_IWSTrust13Async policy uses this endpoint https://yourcompany.com/adfs/services/trust/13/UsernameMixed
Do I need to disable this endpoint to make my app work? It was mentioned here the endpoint needs to be disabled.
https://community.dynamics.com/crm/f/microsoft-dynamics-crm-forum/144495/the-authentication-endpoint-username-was-not-found-on-the-configured-secure-token-service
I have asp.net mvc3 application with forms authentication. But the our client request AD authentication as well. But the mvc3 app is hosted outside the clients network. What are the possible solutions for this.
Get permission to access the clients network from remote server.
Get an API to access the active directory data from webserver.
If we choose opt one how could we access active directory for authentication from outside the client network. I anybody have any idea or better options please let me know. Thanks in advance.
My guess is that the Microsoft security products can support this out of the box but I'm not sure how so I suggest that you direct your question to whoever supplies your client with their Microsoft product support.
If you'd rather build a solution so that you've got more control over how it works a quick search found an interesting approach at https://support.freshservice.com/support/solutions/articles/169196-setting-up-active-directory-single-sign-on-sso-for-remote-authentication where they created a simple ASP.Net web site that used AD authentication for sign-on. MVC 5 can build a WebApi site that does that just by creating a new project in Visual Studio with the right options.
That site wouldn't have to do anything except confirm that the credentials supplied were valid or not. Your application would ask the user to enter login / password details, then send a (properly secured) web request to the authentication site to determine whether they're valid. As long as you keep the communication between your server and the client web service tightly secured this should do what you need without much fuss. That approach removes the need for your server to communicate directly with the client's AD server.
We are having a hosted web application and it uses forms authentication.
This webapplication is accessed by users belong to different partner organizations.
Currently users belong to the partner organizations are accessing the application using the credentials that we give it to them.
Now, some partner organizations wants their users to access the application using their active directory credentials.
We are planning to use ADFS for these partner organizations, so the users will be authenticated using Active Directory within their network and claims will be sent to the webapp via the Authentication token cookie set by the ADFS. From the claims, we map the users to the internal userIds of the web application.
My questions are , if we make the web application ADFS enabled,
1)Is it possible to still allow the other partner organization users(who don't want to use ADFS) to login to the web application using the existing login page(forms authentication)?
2) Should every page in the ADFS enabled webapp be accessed through https?
Any solutions or pointers would be much appreciated.
Thanks
-arul
Your app needs to require claims that describe the user, regardless of where they login from. It should not handle authentication in either case; this should be delegated to a trusted issuer, an STS. This will allow it to interact w/ users in a uniform way irrespective of where and how they authenticate. This means that you're going to need to use ADFS in two roles: that of an Identity Provider (IP) STS and of a Federation Provider (FP) STS. For users of partner companies that don't want to maintain users themselves, you'll be the IP-STS; for those that do, you'll be an FP-STS. In the latter case, ADFS will redirect users from your realm back to the partner's site where their IP-STS will authenticate them and send them to your FP-STS. It will map your partner's user ID and claims into ones that make sense in your realm. This and other information about the user will be included in the set of claims that are issued from your FP-STS. As a result, your app, only trusts your STS regardless of which scenario is appropriate for different users. Note that in this scenerio, there will be two STSs: your ADFS FP-STS and your partner's IP-STS, which may or may not be ADFS. In the other case, there will only be one STS: your IP-STS.
Not every page on your ADFS Web app needs to be accessed via HTTPS; however, everyone that's used in the authentication process should be.
This is really a non-trivial undertaking. If you want to talk about it more, please feel free to get in touch w/ me.
We have three servers that all share the same database. One server is internet facing.
I have a web page in an IFRAME in CRM that talks to the CRM web service using the standard method of connecting for on-premise. When this IFRAME is displayed through the IFD with users logged in through the forms authentication element, you are asked for login credentials.
How do I get around this?
EDIT
The IFRAME that targets the CRM service is on four servers. Two of the servers are used for IFD and On-premise use. The other two are for on-premise only. They are all in the same domain. All of the users are internal users that can log in through the web if they are using a customer's computer or a machine in an Internet cafe and therefore can't use the VPN.
A few questions to better understand you issue. Is the iframe which targets CrmService on the same IFD server? Is the IFD server on the same domain as the rest of the servers? When you say users are logged in are you refereeing to local domain users or external users?
I suspect the problem is not the services, but the IFrame. When you authenticate to MSCRM via on-premise you are doing Windows Authentication, and when you should the IFrame that authentication request is done again. Since the browser knows everything it needs this is all handled transparently.
When using IFD, you are not using authentication on the web server level - you are doing it using forms based which is on the application level. You IFrame though is still wanting authentication, and thus the iframe prompts for authentication.
If you were having a service problem, the IFrame would display and what ever action triggers the service call would fail with a 400 or 500 error.
So the question comes in how do you build a web page that can cater for windows authentication and forms based? Well that is easy in MSCRM, first make sure you are not running authentication on the web page - set it to anonymous. That ensures no more popups, then make sure you use the CrmAuthenticationToken code to get the token and use that for all calls. You should not be setting the .Credentials property of the service itself.
Assuming you're deploying your page within the CRM website (and not its own virtual directory) then here is pointing you at the SDK article for what Robert mentioned:
See the SDK topic titled: Authentication from an ASPX Page.
In my experience you should always use the CRMImpersonator in your web pages within the CRM website.
Now if you've got your own page running on its own website:
You'll want to see the Discovery service and obtaining a CRM Ticket for accessing the services.