Bug 976716 - FreeIPAs XMLRPC server returns a wrong Content-Type
FreeIPAs XMLRPC server returns a wrong Content-Type
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa (Show other bugs)
6.5
Unspecified Unspecified
medium Severity unspecified
: rc
: ---
Assigned To: Martin Kosek
Namita Soman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-21 05:29 EDT by Stephan Adig
Modified: 2013-11-21 15:53 EST (History)
5 users (show)

See Also:
Fixed In Version: ipa-3.0.0-31.el6
Doc Type: Bug Fix
Doc Text:
Cause: Identity Management XML-RPC interface sometimes did not return correct Content-Type header in it's replies. Consequence: Programs or scripts processing the XML-RPC response may report validation error due and stop processing the response. Fix: XML-RPC responder was fixed to return correct Content-Type in reported situations. Result: Programs and scripts can call the Identity Management XML-RPC interface even with strict validation enabled.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-21 15:53:59 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephan Adig 2013-06-21 05:29:59 EDT
Description of problem:

I am trying to access the XMLRPC Server of FreeIPA via Rubies XMLRPC::Client.
This doesn't work, because the service itself sends out Content-Type: text/plain

which is wrong in terms of XMLRPC. Ruby itself has a strict sanity check in its XMLRPC Client, and throws an Exception when the returned Content-Type is not text/xml

Version-Release number of selected component (if applicable):
3.0.0-26.el6

How reproducible:

use XMLRPC::Client of Ruby 1.9 and some gssapi magic to send out the kerb authentication headers.


and use this code:

For example you can use this code:


require 'xmlrpc/client'
require 'base64'
require 'gssapi'

class FreeIPA
        attr_accessor :ipaurl
        attr_accessor :kerb_service

        def initialize(ipaurl,kerb_service='HTTP')
                uri=URI.parse ipaurl
                @ipaurl=ipaurl
                @kerb_service=kerb_service

                @ipa=XMLRPC::Client.new2(@ipaurl)
                @ipa.instance_variable_get(:@http).instance_variable_set(:@verify_mode, OpenSSL::SSL::VERIFY_NONE)

                @gsscli=GSSAPI::Simple.new(uri.host,@kerb_service)

                @token=@gsscli.init_context

                @ipa.http_header_extra={
                        'Authorization'=>"Negotiate #{Base64.strict_encode64(@token)}",
                        'Referer' => @ipaurl,
                        'Content-Type' => 'text/xml; charset=utf-8',
                        'Accept' => 'text/plain'
                }
        end

        def user_list
                user_list=@ipa.call('user_find')
                user_list
        end
end



a=FreeIPA.new('<your ipa server url i.e. http://ipaurl/ipa/xml>','HTTP')
puts a.user_list


Steps to Reproduce:
1. adjust the ipa url in the script
2. kinit <kerb user which has write to admin IPA>
3. start the script

Actual results:
ruby kerb.rb 
/usr/lib/ruby/1.9.1/xmlrpc/client.rb:557:in `do_rpc': Wrong content-type (received 'text/plain' but expected 'text/xml') (RuntimeError)
	from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:420:in `call2'
	from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:410:in `call'
	from kerb.rb:30:in `user_list'
	from kerb.rb:39:in `<main>'



Expected results:
ruby kerb.rb 
{"count"=>3, "truncated"=>false, "result"=>[{"dn"=>"uid=admin,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["admin"], "loginshell"=>["/bin/bash"], "uidnumber"=>["723200000"], "gidnumber"=>["723200000"], "has_password"=>true, "sn"=>["Administrator"], "homedirectory"=>["/home/admin"], "nsaccountlock"=>false}, {"dn"=>"uid=sadig,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["sadig"], "loginshell"=>["/bin/sh"], "uidnumber"=>["723200001"], "gidnumber"=>["723200001"], "has_password"=>true, "sn"=>["Adig"], "homedirectory"=>["/home/sadig"], "mail"=>["sadig@intern.sourcecode.de"], "givenname"=>["Stephan"], "nsaccountlock"=>false}, {"dn"=>"uid=shermann,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["shermann"], "loginshell"=>["/bin/sh"], "uidnumber"=>["723200004"], "gidnumber"=>["723200004"], "has_password"=>true, "sn"=>["Adig"], "homedirectory"=>["/home/shermann"], "mail"=>["shermann@intern.sourcecode.de"], "givenname"=>["Stephan"], "nsaccountlock"=>false}], "summary"=>"3 users matched"}


Additional info:
Comment 2 Martin Kosek 2013-06-21 06:24:28 EDT
I found out that this issue only reproduces when the client is not using the FreeIPA sessions and is doing the full delegation:

# ipa -vv user-show admin
ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/xml
...
reply: 'HTTP/1.1 200 Success\r\n'
...
header: Content-Type: text/plain; charset=UTF-8
...
header: WWW-Authenticate: Negotiate YIGYBgkqhkiG9x...JDIK9jtCPOA4JKDI=
...
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 1059000000
  GID: 1059000000
  Account disabled: False
  Password: True
  Member of groups: admins, trust admins
  Kerberos keys available: True

With second try the session is now used and correct Content-Type shows:

# ipa -vv user-show admin
ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/session/xml
...
reply: 'HTTP/1.1 200 Success\r\n'
...
header: Set-Cookie: ipa_session=503afc96694e344c68d27fe680cd001c; Domain=vm-133.idm.lab.bos.redhat.com; Path=/ipa; Expires=Fri, 21 Jun 2013 10:37:56 GMT; Secure; HttpOnly

...
header: Content-Type: text/xml; charset=utf-8
...
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 1059000000
  GID: 1059000000
  Account disabled: False
  Password: True
  Member of groups: admins, trust admins
  Kerberos keys available: True


Your case can be easily reproducible the following way:
# ipa --delegate -vv user-show admin
ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/xml
...
reply: 'HTTP/1.1 200 Success\r\n'
...
header: WWW-Authenticate: Negotiate
...
header: Content-Type: text/plain; charset=UTF-8

To sum it up, it is indeed a bug and I will clone it to upstream ticket.
Comment 3 Martin Kosek 2013-06-21 06:29:32 EDT
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3745
Comment 6 Kaleem 2013-10-03 10:19:27 EDT
Verified.

IPA version:
============
[root@rhel65-master ~]# rpm -q ipa-server
ipa-server-3.0.0-37.el6.x86_64
[root@rhel65-master ~]#


[root@rhel65-master ~]# ipa --delegate -vv user-show admin
ipa: INFO: trying https://rhel65-master.testrelm.com/ipa/xml
ipa: INFO: Forwarding 'user_show' to server u'https://rhel65-master.testrelm.com/ipa/xml'
send: u'POST /ipa/xml HTTP/1.0\r\nHost: rhel65-master.testrelm.com\r\nAccept-Language: en-us\r\nReferer: https://rhel65-master.testrelm.com/ipa/xml\r\nAuthorization: negotiate YIIFDgYJKoZIhvcSAQICAQBuggT9MIIE
....
reply: 'HTTP/1.1 200 Success\r\n'
....
header: Content-Type: text/xml; charset=utf-8
[root@rhel65-master ~]#
Comment 8 errata-xmlrpc 2013-11-21 15:53:59 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1651.html

Note You need to log in before you can comment on or make changes to this bug.