There is currently a fixed relationship between a users loginname and their JID.
At the moment JID = loginname & “@” & servername
I was hoping we’‘d be able to break that relationship; we use LDAP Integration. The side effect of that is that if I want to give my JID to someone outside the company, I have to tell them my Windows username - I’'d obviously like to avoid that.
Ideally, I’'d login with a AD username, and my JID would be generated from another property in the LDAP directory.
In an ideal world, I’'d have another line in the mapping file which said JID maps directly to the Active Directory attribute ‘‘mail’’.
I realise I can change the mapping so that I login using a different field. However, that doesn’'t solve my problem for 3 reasons:
Users know their username. Telling them to ‘‘use your email address, but chop off the @domain.name as a username’’ won’'t go down well.
I’'d like to use SSO. At the moment that works by taking my AD Kerberos principal name and chopping off the @ and everything after it. In simple terms, SSO will only work if I setup Openfire to accept the AD attribute SAMAccountName as my login.
The ‘‘mail’’ attribute in the Active Directory includes the @ sign and the suffix. I can set my Openfire XMPP domain name to be equal to the same as my email suffix. However, if I map username to mail, I end up with a JID of emailprefix@emailsuffix@emailsuffix, which just isn’'t what I want!
Anyone know if this is easily fixable? Surely I can’'t be the only Openfire user who wants such a feature?
I was planning on creating an appropriate field in the directory (by taking my email address and getting rid of the suffix). However, I can nolonger do that if I want SSO to work.
There is currently code in place that will resolve some of this issue. Sadly, I dont know of any client that supports it (even Spark, yet).
The code is in the authorization provider, which allows principals to authorize to users. This was written with GSSAPI in mind, but applies equally well to other places too. If you are using LDAP, you can qurey specific fields to do this.
However, this is passive. The client needs to request the authorization ID it wants. Ive been trying to think of a good way to have openfire just assign a different JID, but have not made much progress in this area yet- it will require a bit more refactoring I think.
The second problem is with clients. There are two ways to authenticate: You can ask for a specific authorization ID, or you can just leave it blank. Most Jabber clients out there have no way to specify anything in their interface, but use a variety of different means of authenticating. Im going to focus on Spark (because, well, you know…). With the next SSO code, you will be able to specify a different username than what you authenticate with, so that will solve part of the problem. But then, in the interface itself, if you leave the defaults it will ask for that username, not asking for the default. Again, I dont know the best way to tackle this yet. Im hoping that some of the Jive guys will have some time to discuss this.
Thanks for that. Nice to know it’'s been considered! I package Spark for my users, so if I could:
Set a property on Spark to use SAMAccountName as the login name
Configure Openfire to map username to a different LDAP field, which I generate (which just happens to be the first part of their email address before the @)
Then, I should get what I want. However, it’'s obviously none too elegant!
I also notice that in the database information about gateway registrations and roster items are stored with reference to the local user’‘s username, not JID which isn’‘t ideal as I’'ll have to manually update them all!
Re #1: There wont be any property to set in Spark for the login name when using SSO, it will acquire that from the credentials on the workstation.
Re #2: That s the goal, but the design is still muddy at this point. Since I know you have this kind of environment, Ill let you know when I have something if you dont doing mind some testing.
The database stores information as the node portion of the JID. So, we have lots of “usernames” now, so let me try to describe the whole ideal setup without using that word.
Spark will authenticate to Openfire using the principal from the credentials on the workstation. That principal may request a JID node-name, or request Openfire to assign it one.
Openfire will then look up the node-name if needed, then authorize the principal to that node-name.
The database will then store roster and other settings based on the node-name.
Really, the principal will not be known to Openfire once authorization occurs, or the outside world ever.