I am using solace as middle-ware for client and server communication.
I want to move from none to kerberos authentication.
Servers are unix and already configured for kerberos authentication.
Client is .Net desktop gui application. And there are be multiple users.
I have some question regarding client kerberos authentication.
Do we need keytab file to connect to server and keytab file should be common for all users Or keytab file should be create with each users credentials.
What if the password changes?
Do we need to ask users to install java to get kinit or krb5?
What are the setting/configuration required on client side?
Thanks in advance..!
You do need to add a keytab to Solace's /keytabs directory. To configure the keys from the keytab tab to Solace's registered key table after the file has been added, enter the following Kerberos Keytab Authentication CONFIG CLI command:
solace(config-kerberos keytab)# add-keytab <keytab-filename> <index>
The number of keytab files is completely dependent on your setup. Typically, there will one keytab file per IP address that is common for all users but if your setup requires greater control, you can add up to a total of 48 keytabs.
When you change your Kerberos password, you will need to recreate and re-add all your keytabs.
The client-side API requirements for a client to use Kerberos authentication do include using the appropriate Java distribution or installed Kerberos libraries for the messaging API that is used. For .NET applications, the SSPI that is distributed with Windows is used, so Java is not required.
A client application must also set the authentication scheme to Kerberos for the respective session. In .NET, this is done with the SessionProperties.AuthenticationSchemeKRB session property. You can also set the Service Principle Name with the Session.Properties.KRBServiceName session property.
Related
I am writing a set of Puppet modules that deploy WSO2 ESB & Identity Service and the API & authentication services we are providing to a client.
For the most part, I have been able to figure out which XML config files I need to update to automatically configure the WSO2 product.
However, I can't work out how to automatically provision an OAuth2 service provider via the config files. I can create and successfully use an OAuth2 service provider through the Identity Service mgmt console, however I'd really rather not have to do that as a manual step when my aim is to configure a set of machines using Puppet to automatically provision an OAuth2 provider.
To confirm, screenshot of the UI below that I am trying to apply settings for via an XML config file, rather than having to do it in the UI:
After some googling, is the correct directory /repository/conf/identity/service-providers?
If so, could somebody point me in the direction of an example where this is used for configuring an OAuth2 service provider?
If not, any more pointers would be gratefully received!
Many thanks
Chris
In case of searching configuration file for adding OAuth configuration without management console UI, you are in the right place. As you specified you can use the configuration in /repository/conf/service-providers/default.xml.
When you add service provider you have to call IdentityApplicationManagementService. You can use IdentityApplicationManagementServiceStub to call IdentityApplicationManagementService. When you add OAuth configuration you have to call OAuthAdminService. You can use OAuthAdminServiceStub to call OAuthAdminService. After creating the service provider and OAuth configurations separately, you have to bind service provider with created OAuth configs.
Note that I will recommend to check the source code in UI classes which used to add service providers, OAuth configs and binding those two. Hope this helps.
Recently I'm doing some experiment with AD and Spring Security Kerberos. I'm not sure is this a bug or did I mis-configured some settings.
I have 2 domains (domain1 and domain2). Domain1 and domain2 are not in the same forest and doesn't have any trust between them.
Domain1 has a spn (HTTP/test-server.domain1.org). Another HTTP application running on a different server has a keytab generated in domain1 and this tie to the spn we have earlier.
In domain2, I added the same spn I have for domain1 (HTTP/test-server.domain1.org) into it. On the other hand, I have a win7 client that's a member of domain2, and when I tried to do a SSO to the HTTP application, it allows me to go through. Could this be a security issue? Because It seems that the keytab I have in the HTTP application is generated in domain1 and tied to a user in domain1 as well.
When you have a keytab file, you are using Kerberos, against AD like you stated. You generate the keytab and map it and the SPN to a user account on the domain, that is used to query AD. You have to note that when Kerberos authentication fails, browsers fall back to the next authentication mechanism by priority. In this case, it would be NTLM, which is a Microsoft authentication mechanism that they are phasing out as it is less secure, but it can easily and automatically pass windows logon credentials to a web server. This could and likely will explain the behavior that you are seeing.
I am trying to use this username in my code but I do not know if it is provided in the environment variables. Thanks!
Additional information: I am using using PingFederate and Ping One.
My website is based on C sharp and it used to get the windows environment variable for username. now I want it changed to the user logged in through ping identity.Is it possible to do so and in that case which SDK should I get (I am assuming the .net integration kit right?)?
As a .NET hosted application on IIS, your application would be considered the Service Provider (SP). In this architecture PingFederate is the Identity Provider (IdP). This is a brokered authentication design pattern, or more commonly known as Single Sign-On (SSO). When PingFederate authenticates the user, a token is sent to your application that would contain the username. The code (or library) within your application would process the token and then read out the username.
Here’s a list of options that you could pursue to solve your problem:
WS-Federation protocol using the Windows Identity Foundation (WIF) libraries. The config on the PingFederate side is very simple, and you just have to integrate the WIF libraries on your side. Once the WIF libraries and associated web.config configuration is established, you read the claims object passed to your application.
OpenID Connect (OIDC) protocol using the OWIN middleware. This is also a native MS solution that leverages an open standard. It will require that you have some understanding of OWIN/Katana, as examples are not exactly exhaustive online. PingFedeate supports the OIDC protocol, which is also a very straight forward configuration.
PingFederate Agentless Integration Kit. The integration kit is installed on PingFederate and is easy to configure. It is essentially a REST interface between PingFederate and your application to provide a JSON object with the identity information including username. Your application would need to implement the REST APIs to PingFederate.
PingFederate .NET Integration Kit. This solution implements the PingFederate Opentoken solution for exchanging attributes between your app and PingFederate. The .NET code libraries for handling the Opentoken are provided to you by the integration kit, you just have to integrate them into your code baseline along with about 10 lines of code to read the OpenToken to get username. Configuration on PingFederate is simple.
Am new to ADFS and LDAP, our project is mixed of technology mongoDb, nodeJS and rails. we are planning on deploying mongodb, Nodejs or Rails on Windows Azure, as LDAP is been used for active directory on ruby.how LDAP used in window azure. is there any performance change in using ADFS in ruby compare to LDAP in ruby. if yes, how can i implement ADFS on RUBY
Is anyone know how its possible. thanks in advance.
Is your LDAP server going to stay on-premises? Just to be clear, ADFS is not equivalent to LDAP. ADFS is a "Security Token Service" (STS). LDAP is a Directory.
Since you mention ADFS, presumably your apps will authenticate users on (on-premises) Active Directory. ADFS can only authenticate users on AD, not on arbitrary directories.
To connect your node.js and ruby app to ADFS you would need to implement either WS-Federation or SAML Protocol. These are the 2 protocols supported by ADFS. You can read more about it here.
Alternatively, you can implement your own STS and connect it with whatever you want (ADFS or LDAP). If you do this, then you have more control on what kind of protocols to implement in your app (e.g. OAuth2 or something else). It seems there are more libraries you can leverage compared to WS-Fed / SAML.
There are many open source STSs you can look at. IdentityServer is one of them, and people have successfully built solutions on it. You will have to host this yourself.
Another alternative is to rely on a 3rd party service like Auth0 (which is available on the Windows Azure store). (Disclaimer: this is a product I'm working on).
I recently read about Kerberos and its great algorithm to securely authenticate user.
But the "drawback" of Kerberos is that it requires credentials (calls "principals") to be added manually directly from the authentication server (implemented with Kerberos so).
So, unless I ignore it, it's impossible to use a classic form in an e-commerce to add a NEW user to Kerberos. Indeed, obviously, it will waste Kerberos principle because credentials would be sent over the network, even if they are encrypted with SSL...
Could you confirm me or not that Kerberos cannot be use for classical Web Site requiring each user to create themselves adding their own login/pass? That means without need of Kerberos server's administrator.
You can, in terms of technical capabilities, use Kerberos as the backing store for authentication information and still support username and password over SSL. It's not the ideal Kerberos model, since it means that a system other than the local system the user is sitting in front of gets a copy of the password. But that just means that you're not using the full security capabilities of Kerberos; it doesn't mean that Kerberos won't work. It may still be convenient to use Kerberos for other reasons.
One of the dirty little secrets of Kerberos is that nearly every site that has deployed it on a large-scale basis accepts username and password over SSL for at least some applications and validates the username and password on the server. There just isn't any other good way to do it in a lot of cases. This is particularly true of web applications. While many web browsers do support SPNEGO via Negotiate-Auth to do a real Kerberos authentication, this doesn't work in a wide variety of situations (no Kerberos locally on the system, kiosk system, phone device with no local Kerberos libraries, etc.).
(I'm the Kerberos administrator for Stanford University and also the maintainer of our web authentication system, which is based on Kerberos but still, for most users, takes username and password over SSL and verifies them on a central web login server.)