How authentication in general (Mutual Authentication as a special case) works in MSDTC and how to configure Mutual Authentication on MSDTC??
I've a custom application (archival solution), a windows service which on a configured time fetch data from online database and dumps to a back-end archival database (Ideally online and back-end DBs are located on different machine).
I am using TransactionScope and have configured DTC on client and host machine with no authentication and it's working fine. However, our client requires us to not use no authentication mode and put some authentication for MSDTC. I've decided to use mutual authentication though I am not very much sure how it works and how to configure it?? Any help would be appreciated.
Related
I have an authentication/authorization server that currently uses a local ADAM instance to hold the authentication and authorization information for use by a Service Provider (SP).
What I want to do is change from the ADAM instance to a remote ADFS for authentication and authorization. The remote ADFS talks SAML but the Service Provider (SP) only talks with LDAP (and I cannot change the SP to talk SAML).
This suggests that I need to provide a LDAP to SAML converter (or bridge) to produce SAML messages from the SP's incoming LDAP authentication and authorization requests.
Currently it's like this:
LDAP
SP <------------> Authentication Server
I want it to look like this:
LDAP SAML
SP <------------> Authentication Server w/LDAP/SAML bridge <------------> ADFS
So essentially the current authentication server will cease to authenticate itself and will
merely act as a "proxy" for passing on authentication/authorization requests and relaying
responses back to the SP.
Is this possible?
Does anyone have experience with this sort of effort?
Are there any tools on the Net that could perform this bridge functionality?
The current authentication/authorization server runs on gasp Windows 2003 but I do have the
option of porting it to a newer version of Windows Server.
I have tried using OneLogin with the SAML toolkit/Flask websever, and writing my own Python module for handling the SP's requests but I'm getting bogged down with that code (and exposing my own Python limitations)
I also tried SimpleSAMLphp but determined that the LDAP stuff they support is for the IDP side rather than the SP side. The system performs SP-side initiatation.
Have you considered using ADFS to LDAP directly?
Your application would then use ADAL / MSAL to connect.
I am pretty new to Authorization/Authentication with openid connect. I guess I lack some basic understanding on how to set up a proper backend infrastructure.
There's a keycloak server running through which I want to authorize/authenticate my customers.
The user logs in by his company credentials and then should be authorized/authenticated against our backend service, which provides a REST-API.
So our part is to implement the backend service and use openid connect as authorization/authentication.
Could you tell me what components/software needs to be implemented on our side?
Often the Authorization Server is an external cloud system that your UIs and APIs just point to, with URLs equivalent to this:
https://api.mycompany.com/myapi
https://web.mycompany.app/myapp
https://login.mycompany.com
Not sure if this quite matches your setup but typically you provide some or all of these domains:
API
Web Hosting
Authorization Server (Keycloak)
My personal preference is to use Local Developer PC Domains to match the above. If it helps you might just be able to repoint my Open Id Connect
Code Sample to your infra once configured, in order to verify that it works.
Is there an advantage in using a trusted connection vs a sql login for web application? Is there any pros/cons from one to another?
I usually use Windows Authentication, which is more secure, with a service account. If you are doing an internal application within your own domain and you want to authenticate your users to the database server, you will need to set up delegation on that service account along with the IIS and SQL services. If it is outward facing or you aren't concerned with authenticating users to the database, you simply need to give the relevant permissions to the service account login in SQL. In either case, assuming your webserver is IIS, you would change the web application to run under the service account. This will encrypt and store the credentials on the webserver.
The main reason windows authentication is more secure is it makes use of the Active Directory infrastructure to authenticate users using encrypted messages between the servers. With SQL Authentication the credentials are passed across the network. If you do use SQL Authentication, you should make sure to encrypt the connection string portion of your web config, as you would embed the credentials including the password.
After some theoretical help on the best approach for allowing a SaaS product to authenticate users against a tenant's internal Active Directory (or other LDAP) server.
The application is hosted, but a requirement exists that tenants can delegate authentication to their existing user management provider such as AD or OpenLDAP etc. Tools such as Microsoft Online's hosted exchange support corporate AD sync.
Assuming the client doesn't want to forward port 389 to their domain controller, what is the best approach for this?
After doing some research and talking to a few system admins who would be managing this, we've settled on an two options, which should satisfy most people. I'll describe them here for those who were also interested in the outcome.
Authentication Service installed in the origanisation's DMZ
If users wish to utilise authentication with an on-premises active directory server they will be required to install an agent in their DMZ and open port 443 to it. Our service will be configured to hit this service to perform authentication.
This service will sit in the DMZ and receive authentication requests from the SaaS application. The service will attempt to bind to active directory with these credentials and return a status to indicate success or failure.
In this instance the application's forms based authentication will not change, and the user will not be aware of the authentication behind the scenes.
OpenId
Similar to the first approach, a service will be installed in the client's DMZ, and port 443 will be opened. This will be an OpenId provider.
The SaaS application will be an OpenId consumer (already is for Facebook, Twitter, Google etc login).
When a user wishes to log in, the OpenId provider will be presented, asking them to enter their user name and password. This login screen would be served from the client's DMZ. The user would never enter their username or password into the SaaS application.
In this instance, the existing forms based authentication is replaced with the OpenId authentication from the service in the client's DNZ.
A third option that we're investigating is Active Directory Federated Services, but this is proprietary to Active Directory. The other two solutions support any LDAP based authentication across the internet.
Perhaps this might help…
This vendor, Stormpath, offers a service providing: user authentication, user account management, with hookups to your customers’ on-premise directories.
What about an LDAPS connection to the customer's user directory? They can firewall this off so that only your servers have access if they're concerned about it being public. Since it's SSL it's secure end to end. All you need from them is the certificate from their issuing CA (if it's not a public one). I struggled to get this working for an internal web project in the DMZ and there's a real lack of any guides online. So I wrote one up when I'd got it working:
http://pcloadletter.co.uk/2011/06/27/active-directory-authentication-using-ldaps/
Your best bet is to implement a SAML authentication for your SaaS application, and then sign up with identity providers like Okta or OneLogin. Once that's done then you can also connect it with ADFS to provide Single Sign On for your web application through Active Directory.
I'm just doing this research myself and this is what I've came across of, will have more updates once implementation is done. Hope this gives you enough keywords to do another google search
My understanding is that there are three possible solutions:
Installing something on the domain controller to capture all user changes (additions, deletions, password changes) and send updates to the remote server. Unfortunately there's no way for the website to know the initial user passwords - only new ones once they are changed.
Provide access for the web server to connect to your domain controller via LDAP/WIF/ADFS. This would probably mean opening incoming ports in the company's firewall to allow a specific IP.
Otherwise, bypass usernames/passwords and use email-based authentication instead. Users would just have to authenticate via email once every 3-6 months for each device.
I have to begin implementing this for an upcoming project and I'm seriously leaning towards option #3 for simplicity.
Is it possible to instruct the jabber/xmpp server to delegate authentication to another module? We are building an internal application using XMPP and it would be fantastic if we could let users keep their standard username/password that they use in our web-apps. The web-apps are currently hashing passwords, and so the passwords in the DB are not stored in plain-text form. It would have been easy to share passwords across systems if this were not the case, but then, of course, storing plain-text passwords in the server-side database is a big no-no.
Ideally we could just tell the jabber server "hey, just pass off your username/authentication request to here" and have some other process running (perhaps even just an xmpp bot?) that handles authentication.
We are currently using ejabberd as our server, which I believe is written in Erlang. We're not tied to ejabberd though. I know that XMPP is huge, and largely extensible - but I haven't found anything about extensible authentication on the server side.
I found this on the XMPP website, but that appears to be the protocol for negotiating authentication between the client and the server, not the actual authentication mechanism on the server.
Any pointers on how to merge authentication schemes between an XMPP server and our other systems?
ejabberd has multiple ways to authenticate. You can use LDAP, for example, if you have an LDAP server for your organisation. This works at my company, and provides a single log in for our wiki, ticket system, etc.
Have a look at the section on authentication in the user guide.