I am new to MSCRM trying to adopt its security model and integrate with our existing applications. Need a clear understanding with respect to integration between MSCRM system and our existing applications.
Our current application is uses SiteMinder for authentication, business need is to integrate MSCRM from this application without login challenge again. After going through the claim based authenticaiton, ADFS 2.0, ADFS with SiteMinder documentation, some basic questions,
--> can MSCRM work if federated with ADFS SiteMinder ?
--> If so, how the user setup will work in MSCRM ?
Can any body done these MSCRM - ADFS - SiteMinder integration ? i could find the disjoint documentation ADFS - Siteminder, MSCRM - ADFS, but not so sure if relying application (MSCRM) will work with SiteMinder tokens.
Any suggestions appretiated.
The big question would be if what SAML Defaults your Siteminder is providing.
Setup would be simliar to ADFS 2.0 install the certificate from siteminder on the CRM Server to make him beable to proof the token and tell CRM where it can download the federationmetadata file from siteminder.
Related
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 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.
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.
Microsoft Dynamics 365 supports three security models for authentication: Claims-based authentication, Active Directory authentication, and OAuth 2.0.
I've managed to implement the Active Directory authentication which is based on Oath2.0. What might be the difference between Active Directory authentication and Oath 2.0 and How can I configure OAuth 2.0 security for Dynamics 365. I don't have so much knowledge about Oath or Active Directory.
Based on my understanding, one benefit of using OAuth is that your application can support multi-factor authentication.
You can refer the links below about the detail between OAuth and Active Directory and claims-based authentication:
Connect to Microsoft Dynamics 365 web services using OAuth
Active Directory and claims-based authentication
What did you mean OAuth 2.0 security for Dynamics 365?
I'd like to support multiple authentication mechanisms such as oAuth and ADFS in my MVC site. Is this possible, and how would I go about using one or the other?
My understanding is that ADFS/WIF will hook into the entire site preventing alternates such as oAuth
FedUtil only allows an application to point to one instance of ADFS. If you use it again to point to another instance, it simply overwrites the old ADFS info. in the web.config.
The trick is to federate ADFS with another STS which does support the OAuth protocol.
StarterSTS is an example of an STS which supports OpenId. This was developed by Dominick Baier. He has just announced via his blog that he is developing a MVC version.
Matias Woloski has blogged about a protocol bridge here. It supports not only OpenID but also OAuth.
#nzpcmad suggestion of adding an STS to do protocol translation is correct. Another alternative is to use ACS (AppFabric Access Control Service).
You can alternatively add the trusts relationship on the web.config manually (or run Fedutil on a separate project and merge the changes). In this case the trust would be to an STS that knows how to deal with OAuth and SAML/WS-Federation (like the STSs mentioned by #nzpcmad). Out of the box, WIF only understands SAML tokens and WS-Federation/WS-Trust.
StarterSTS does not support OAuth but the follow-on project by the same guy does. Check out http://identityserver.codeplex.com/ for more details.
In addition to supporting OAuth it is new code using the ASP.NET MVC framework and WCF for its underpinnings.
This is only at CTP 1 status and is not yet considered a full release yet so review carefully.