Spark 2.5.3b1 SSO

wow! that wiki is very heavy going. There was me thinking it would be easy

I’‘m preusming that going forward the number of hoops required to get this working will be vastly reduced and simplified? I’‘ll give this a go but don’'t hold out much hope.

well I tried anyway…and failed. Followed all the steps in the wiki, not sure my keytab was created properly or that I created the right user in thh right place (standard AD user?)

Anyway, long story short, get exactly the same error as those mentioned above.

Well, yes and no. The manual edits in the config should get moved into a wizard. The gss.conf should get moved to a wizard as well. But the keytab procedure is not something openfire can do- that will still be done manually.

It will get better, this is all still very young. Feedback from the initial users will be very valuable.

I have installed the sasl in my Openfire 3.3.1 on windows server. I think it is configured correctly, but I still can not login via SSO. Regular login methods still work fine. The users all use spark on windows, and the server is also on windows. I am at a loss here. This is my new openfire.xml:







]]>

cn

mail

cn

member

description

false

(objectClass=group)

org.jivesoftware.openfire.ldap.LdapVCardProvider

org.jivesoftware.openfire.ldap.LdapUserProvider

org.jivesoftware.openfire.ldap.LdapAuthProvider

org.jivesoftware.openfire.ldap.LdapGroupProvider

org.jivesoftware.openfire.sasl.StrictAuthorizationPolicy org.jivesoftware.openfire.sasl.DefaultAuthorizationPolicy

true

true

… and here was me thinking it would simply attempt to login using the cached Windows password – or is it and there’'s just a lot of security required?

There is a little more to it. Ill try to keep the uber-technical details to a minimum, but here is how SSO works.

We have 3 entities: The user, the service/server, and a trusted third party(Key Distribution Center, or KDC). When the user first logs in, it authenticates to the KDC to obtain its personal key (shared-secret key, for those keeping score). Only the user and the KDC know this key.

The server, when installed, is given a keytab, which contains a key for a service. Again, only the server and the KDC know this key.

So, the user authenticates itself to the KDC once, and is given a “ticket granting ticket” (TGT) which is basicly a short lived session key. When the user would like to authenticate itself to a service, it takes this TGT to the KDC, and asks for a ticket to the service. The KDC inspects the TGT, see’'s that it is still good, and grants a ticket.

This ticket contains several things, but most importantly it contains another session key that the service and the user will use with eachother. This ticket is encrypted with the user’‘s private key, so only the user can open it. In the ticket, the is the same key encrypted with the service’'s private key (which the user dosnt know). The user gives this ticket to the service. The service decrypts it, and now both the user and the service have a private key to share.

Ok- there are a lot of details left out here, but thats the basic process for Kerberos, which Microsoft uses in Active Directory authentication. When you sign onto your workstation on a domain, you are given this TGT, and you use this when you access other resources on the the network without a password (like an exchange server, or some file share). The attempt here is to get Openfire and Spark to work in the same way. However, if your windows workstation is not apart of a windows AD domain, this wont work quite the same way, since it was not granted a TGT at login.

So, your workstation does not cache your password exactly (well, only a small white lie, but I wont explain that), so there is no way to just obtain the password you used from you login and reuse it. If you are just looking for something so you dont have to type your password, Spark can save your password. SSO is much more advanced. Its more secure, but also more complicated. We will continue to work at making it easier for users to set up, but for now its going to cause a few people some headaches (probably me trying to debug it all…)

Thanks, slushpupie for all of the info. I suppose it’‘s a tad naive to believe the password is simply “cached” somewhere – what a security risk it’'d pose!

What are the other benefits of SSO? The main reason I personally want it is because of our setup and users: since we have it automatically install, the users still need to enter their password (at least the first time) which means we can’‘t start Spark minimised as it (at least used to) wouldn’'t login and no one would know about it.

So, what I really want, is for Spark to simply login minimised without the user realising; we have a number of users who close the application as it logs on, and there’'s just as many who want to use it with these users. Very frustrating!

From my point of view, if the application is running and connected in the system tray, it means all the users are contactable using Spark even if they don’'t know it (and a lot of users are scared of new technology!).

I’‘ll have a bit more of a crack at SSO next week; I installed 3.1.0 > 3.3.0 the other day in the middle of the working day and it wasn’‘t appreciated by many (though that’'s good, at least I know people are using it!).

SlushPuppie - the theory is great, it took me back to 101 Computer Science classes (with lecturers running around the lecture theatre with different coloured envelopes containing tickets). about 10 years ago

What I’‘m still not sure of is how this works with regards to Spark/Openfire and whether what we’'re trying to achieve is possible.

From my perspective, what people seem to want is:

  1. Convenience, we don’'t want to have to type passwords.

  2. Security. Most people use Active Directory for user authentication. Therefore in a corporate environment Spark is running on a desktop machine. That machine is probably part of a Windows domain (and therefore Kerberos realm) as is the Openfire Server. We’'d like to use Kerberos from the client to access Openfire.

So, attempting to fill in the blanks; Could you walk us through the Kerberos authentication process using Openfire?

I presume:

  1. You tell Spark the name of the server (i.e. XMPP domain) that it will login to. In my case we use SRV records so locate the server, example.com.

  2. Spark will use the TGT that the user already has obtained from the KDC and request a ticket for the service named ‘‘XMPP’’. So, in our case we need a user in AD (the name of this user is unimportant) and service principal mapped to that user called xmpp/example,com@ADDOMAIN.COM

  3. The ticket we get from the KDC will be encrypted with the servers private key and the users public key. For that reason, we need to ensure we have a KTAB file that Openfire can see to decrypt the ticket. This step is necessary for 3 reasons; to prove the client spoke to the KDC and to ensure we’'re talking to the correct server and to ensure comms with the client are secure

  4. Openfire will then decrypt the ticket authenticate the user.

Throughout the process the ticket exchange protocol ‘‘GSSAPI’’ will be used.

Am I far off the mark?

More questions (sorry!):

  1. The WIKI mentions DNS must be setup for the principal name. I’'ve no idea what that means. As I mentioned earlier, I locate my server using SRV records (xmpp-client etc). So, If I setup a security principal with xmpp/example.com then the A records for example.com will not point to my server. Does that mean this will not work in my environment

  2. Realms. My forest has several realms (i.e Windows domains). Does this mechanism assume that we have a single realm or does reference to the realm in the WIKI just refer to the server/security principal (which in my case lives in subdomain.example.com)?

I hope that make some kind of sense!

D

Has anyone been successful getting this to work in a total windows environment with active directory. Openfire 3.3.1 on windows, Spark 2.5.3b1 on windows, Active Directory for my LDAP. See my previous posts for more specifics and errors.

The biggest reasons to want SSO are simplicity and security.

I dont mean simplicity of setup, though- just simplicity for the user. When a user wants to use some service, the user simply starts the service and the service already knows who the user is, and can trust it with no interaction from the user. Especially for technophobes this is a great thing. It also means users dont have passwords on a bunch of different systems, there is one central location for all of it. You can gain the password centrality with technologies like LDAP, but the password is still being sent.

If you want, there are a ton of sites out there that explain the full Kerberos protocol and why it is secure. In essence, when using strictly Kerberos, your password will never go over the network (encrypted or otherwise). Microsoft’'s version of Kerberos is different, and its possible to negotiate the protocol down to something less secure (NTLM, for example) but as long as Kerberos is being used the security is still there.

A reason you want SSO but may not know it: Its an open standard. Openfire is built on open standards, which allows it to interoperate with lots of other products. By extending to more open protocols, more products will support those same protocols, which helps the community at large.

It may be an open standard but there is no good documentation specific to configuring this on a Windows Openfire 3.3.1 server for SSO access by Spark 2.5.3b1. If there is I can not find it.

DeeJay, sure thing-

Spark, when enabled for SSO, will obtain the “principal” from the “credential cache”. This means the local user account information, and tickets, from when you logged in. A principal in Kerberos can take many forms, for a user it will look like usrename@REALM . If Spark is able to obtain this information, and you told it which XMPP server to use, it then makes a connection to that server (that part is no different than any other client- so SRV records may be used).

When the client and server are authenticating, they are using a protocol called GSSAPI which is a generic protocol for key exchanges, but used heavily in the Kerberos community. The client requests from the KDC a service principal ticket. This service principal is in the form of servicename/hostname@REALM . So for example, our service is xmpp, the host is foo.example.com and our realm is EXAMPLE.COM, the principal would be xmpp/foo.example.com@EXAMPLE.COM . Now, this is where DNS is important. The rules of Kerberos/GSSAPI say you dont request the principal for the hostname you typed in, you request the fully qualified hostname of the IP you ended up at. So lets say your xmpp domain name was just example.com . If you used service records that pointed you to connect to im.example.com, you would look up that IP address, then look up what name belongs to that, lets say it returned foo.example.com. This is why having DNS set up correctly is important, if it isnt you may end up requesting the wrong thing, which will end up failing.

Next, the client sends an authentication token to the server, the server verifies it, and sends a response back. Kerberos is unique in that we can also have the server authenticate to the client (so the client knows the server really is who we think it is), so that exchange happens next.

After we are both authenticated, the server needs to authorize the user. See, the username we sent was a principal, and that may not match exactly the username that Openfire uses. So there are several different policies that can be configured to decide how to do this. If we simply chop off the realm part of the principal, then if the same username existed in multiple realms all of those users could log into the same account (you dont want that). That part of Openfire is pretty weak right now, but Im working on some new stuff that will come out soon.

Hope that answers all of your questions

Slushpuppy - Would you mind taking a look at my last post on this. I was hoping that with your knowledge you’'d be able to help answer some of the question I have remaining.

I’'m in the process of setting up a test server so should be able to get to the bottom of all this and publish an ‘‘idiots guide’’ - i.e. for us non-Kerberos savvy people!!

thanks,

Darren.

mtstravel,

SSO support in Spark is beta quality at best. It has only been tested on Unix systems, and it is apparent there are some intracacies in getting Spark to work on windows that we have not resolved yet. Rest assured, we are working on them.

SSO support in Openfire has existed for a while, but no one has used it except for a few people. Since I implemented that, it was focused around Unix, but I have made it work in a Windows AD before (different client, though).

Why so little documentation? Because this is all very untested and new. Thats why there hasnt been a big announcement around it yet. There are hundreds of ways to configure Kerberos, and we can only possibly test a few. So the first few rounds will be a little painful. If you cant tolerate that on your network, then I suggest waiting for a while. However, if you have tolerant users, or a test network, we would appreciate anyone who can get this working to share their experiences, and perhaps their configuration.

Full Spark+Openfire support for SSO has only existed for a week now. So please be patient with our newborn infant.

I would appreciate any help anyone can offer to get SSO to work with my configuration. I use Spark 2.5.3b1 on windows, Openfire 3.3.1 on windows, and Active Directory. I also asked for help with this in the openfire forum. My error logs from today are there. I am at a complete loss at this point.

I am patient. This server is still in final test mode. It is set for deployment in the middle of June. We have a small test bed of users currently. This will change in June. We will be rolling this out company wide then. SSO would be very helpful.

SP - that does, thanks!

So, the future development work you’‘re doing to may give more flexibility in tieing the two together? Ideally I’'d like my username in AD (LDAP) that I log into the workstation with to differ from the username Openfire accepts.

What I’'d like to do is map to a different AD attribute. Would you future plans allow for that?

This will be required if you’'re using AD and you JID is generated using something other than SAMAccountName as the username field.

thanks,

Darren

Yes! In fact, there is already code in openfire to allow mapping via LDAP queries and database lookups.

Yes, I know

So, I login to my kerberos realm as username@addomain.com

I have an AD attribute called sn, and tell Openfire to map that to my login.

So, I login using normal authentication as surname@example.com which will work fine.

However with SSO/Kerberos you said that the normal provider will just chop the suffix off my username and use that as the name used to login to Spark. So, it’'ll pass username rather than surname.

Does that make any sense?

D

We implemented this using a provider pattern. There are multiple authorization providers, and you can stack them or just use one. So in your case, skip all the others and just use the LDAP one. Honestly, though, I wrote the code for the LDAP one, but never tested it since I dont have the environment to test it with. Sounds like you do, though, so I look forward to seeing it work someplace.