On 07/30/2013 09:11 AM, Matt . wrote: > Hi all, > > We have found something out. > > When you add a user (like cmdtestuser) to FreeIPA and add it to group: > > - admins > - trust admins > - editors
This does not matter really if you just trying to do authentication. This would matter if you start to execute administrative commands with the user. As a starting point putting user into admins group would enable him to do everything. However in general we suggest that you Identify operations that your application would perform Identify permissions and privileges needed for those operations Create a role that grants those privileges Associate the user to the role (directly) or via a new group that you would create. Bottom line after you sort out the authentication and ticket delegation you would need to think about access control and reduce the privileges of your PHP application to only operations it really needs to perform. > > And you add this same useraccount to a Linux box and do a "su > cmdtestuser" you are able to do a "kinit" abd give your password that > user has in FreeIPA. How do you "add" it? Do you actually define a local user? That would be wrong. > > After this you can run a curl script from the commandline with a > "add_user" and actually add that user to IPA. So that works. Yes because you effectively ran a ipa user-add command just yourselves using curl. > > That is what we actually want to do from PHP but testing this with a > HTTP/HTTPD user in IPA doesn't work. > Are you talking about local HTTP user that was added to the local /etc/passwd file? Of cause it would not work. You need to run your application using a user (principal) that IPA (Kerberos) recognizes. > Shouldn't that be possible ? It is possible. And you can do it two ways: you can use end user identity to perform operations against IPA or you can give privileges to the PHP application to perform operation using its own identity. The former is preferable. In the latter case you sort of hand keys to the kingdom to the PHP application and even if you confine its privileges as I described above you would have to build access control into your PHP application if you want to allow different admins to perform different operations via your PHP application. So the best would be to use user identity so please use Alexander's article and make your PHP application acquire ticket on user behalf. Make your users members of the admin group for testing purposes to sort the authentication issues but once done define the right privileges for them so that they can execute only the commands that they are entitled to execute. HTH > > I hope so! > > Cheers, > > Matt > > > > > 2013/7/26 Petr Vobornik <pvobo...@redhat.com <mailto:pvobo...@redhat.com>> > > On 07/26/2013 04:37 PM, Rob Crittenden wrote: > > Zip Ly wrote: > > > Normally if IPA has a well documented API then my approach > would be: > user --> (internet) --> webserver --> lPA API --> IPA server > But since there isn't much info about the API then my > approach would be: > user --> (internet) --> webserver --> a PHP script which > acts as an > custom API --> IPA serve > The problem is I don't know which commands are available > en which > values/params I should send. For example: > > http://www.freeipa.org/docs/1.2/Administrators_Reference/en-US/html/chap-Administration_Reference-XML_RPC_Application_Programming_Interface_API_Documentation.html# > > These are commands for xml rpc. Without examples it's > difficult to find > out how to use it. > > > The API changed between v1 and v2/3, so these docs are not > right for > your purposes. > > We haven't formally documented the API (either json or > xml-rpc) yet > because it is still somewhat in flux. The API is baked into > the ipa > client, so any command you can run from there is the > equivalent of a > json/xml-rpc command, just substituting underscore for dash. > > About the closest we have is API.txt in the source tree. This > is really > designed to be read by a computer but it outlines each command > and the > options it takes, and the output it returns. > > But they are different from this example: > > http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ > > In this example a "user_find" command is used, but this > command cannot > be found in the official xml rpc document above. > In ssh I can display a list of commands with "ipa help > commands" I don't > know if they are all supported in "/ipa/json" I probably > need to replace > all dashes with underscores (correct me if I'm wrong). > > > The same commands and options are available over json as xml-rpc. > > If I want to display all the supported params from one > certain command > for example "ipa help user-find". Then, are all the double > dashed params > also the supported params which I can send with JSON? > > > Yes. > > > Note that for some LDAP attributes dash param names may be > different than API option names. It those cases the correct one is > LDAP attribute name. > > Use `ipa show-mappings command-name` to find the correct names. > > > > I prefer using the native API if there is one (hidden > somewhere), > because I don't want to reinvent the wheel with security > leaks which I'm > not aware of. Especially when I need to execute CLI > commands from > the PHP scripts. > > > The native API is json/xml-rpc. They are currently equivalent. > In the > near future we are going to mark xml-rpc as deprecated and it > will start > to fall behind in features, and eventually we may drop it > altogether. > > rob > > > -- > Petr Vobornik > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users@redhat.com <mailto:Freeipa-users@redhat.com> > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
