-
Notifications
You must be signed in to change notification settings - Fork 0
/
cumin.xml
177 lines (117 loc) · 12.5 KB
/
cumin.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title><![CDATA[Mostly Cumin]]></title>
<link href="http://tmckayus.github.com/atom.xml" rel="self"/>
<link href="http://tmckayus.github.com/"/>
<updated>2012-11-12T15:29:45-05:00</updated>
<id>http://tmckayus.github.com/</id>
<author>
<name><![CDATA[Trevor McKay]]></name>
</author>
<generator uri="http://octopress.org/">Octopress</generator>
<entry>
<title type="html"><![CDATA[Role enforcement in Cumin]]></title>
<link href="http://tmckayus.github.com/blog/2012/11/12/role-enforcement-in-cumin/"/>
<updated>2012-11-12T15:20:00-05:00</updated>
<id>http://tmckayus.github.com/blog/2012/11/12/role-enforcement-in-cumin</id>
<content type="html"><![CDATA[<p>Roles in Cumin scope activities and content in the UI. There are currently two roles defined in Cumin, <code>admin</code> and <code>user</code>. The <code>admin</code> role is a superset of the <code>user</code> role, and every new account has the <code>user</code> role by default.</p>
<h3>Differences in the Roles</h3>
<p>The <code>admin</code> role allows a user to see various charts, graphs, and statistics related to performance of the Condor pool. An admin can also see information about Condor infrastructure components such as schedulers and negotiators and can run certain pool management commands. Admins are free to manage any job running in the pool regardless of who owns the job, but can also switch to the <code>user</code> view for the admin account.</p>
<p>The <code>user</code> role allows a user to create and manage their own submissions. They do not have visibility to jobs owned by other users, performance metrics, or pool management commands.</p>
<h3>Enabling Role Enforcement</h3>
<p>Role enforcement is disabled by default in the standard Cumin configuration file, effectively making every user an admin (the default will change in a future revision). To enable role enforcement, set the <code>auth</code> configuration value to <code>True</code> in the cumin.conf configuration file:</p>
<pre><code>[web]
authorize: True
</code></pre>
<h3>Setting Role Values</h3>
<p>The role value is part of the account metadata along with username and password. While username and password may optionally be managed in LDAP repositories, role values at this time may only be defined in the local PostgreSQL database. This restriction will likely be removed in a future version. You can read more about LDAP authentication in the earlier blog post <em>Cumin Authentication with LDAP</em>, and we’ll explain how to set roles for external user accounts below.</p>
<p>Roles are managed with the <code>cumin-admin</code> commands <code>add-assignment</code> and <code>remove-assignment</code>:</p>
<pre><code># cumin-admin add-assignment joeuser admin
# cumin-admin remove-assignment joeuser admin
</code></pre>
<p>(An account may have the <code>user</code> and <code>admin</code> roles at the same time, but currently this has no real effect since <code>admin</code> is a superset. It is not necessary to explicitly set the <code>user</code> role.)</p>
<h3>Creating an Entry to Hold the Role for an LDAP Account</h3>
<p>For accounts authenticated against LDAP, an entry must be added to the PostgreSQL database as a placeholder before the role value may be set. This is done with the <code>cumin-admin</code> command <code>external-user</code>:</p>
<pre><code># cumin-admin external-user myldapuser
# cumin-admin add-assignment myladpuser admin
</code></pre>
<h3>More to Come</h3>
<p>A future post may address the relationship of roles to <em>persona</em> and talk about development hooks that allow customization of the UI based on user and site profiles.</p>
<p>The Cumin project wiki can be found <a href="http://fedorahosted.org/grid/wiki/Cumin">here</a></p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Credentials in LDAP URLs when Anonymous Search is Disabled]]></title>
<link href="http://tmckayus.github.com/blog/2012/10/10/ldap-credentials/"/>
<updated>2012-10-10T16:55:00-04:00</updated>
<id>http://tmckayus.github.com/blog/2012/10/10/ldap-credentials</id>
<content type="html"><![CDATA[<p>Cumin authenticates logins against LDAP using a two step process:</p>
<ul>
<li>Search for LDAP entries based on the login name and the search filter in the LDAP URL</li>
<li>Attempt a simple bind operation using the distinguished names (dn) in returned entries and the password</li>
</ul>
<p>If anonymous access is disabled by the LDAP server, the first step will fail. In this case, Cumin needs to bind to the server with credentials before doing the search for user records. Happily, the URL syntax allows for credentials in the URL and Cumin will use them if provided to bind before the search.</p>
<h3>Extra Attributes</h3>
<p>The credentials for an initial bind can be set using LDAP extensions supported by the ldapurl module. There are two additional attributes:</p>
<ul>
<li>bindname (a formal dn corresponding to an LDAP entry)</li>
<li>X-BINDPW (a password that will work for that entry)</li>
</ul>
<p>These attributes follow the filter specification and are separated by a comma. Any comma (,) characters present in the bindname value must be html-escaped because the URL parser will see them as attribute separators. Futhermore, the % character in the escape code for a comma must be escaped itself to prevent Python from seeing it as a string substituion sequence. Simple, right?</p>
<h3>An Example</h3>
<p>Let’s assume the following:</p>
<ul>
<li>The LDAP server is at example.com:389</li>
<li>The search dn is ou=People,dc=example,dc=com</li>
<li>The search scope is sub</li>
<li>The filter compares uid to username (this is actually the default)</li>
<li>The dn for an initial bind is uid=joeuser,ou=People,dc=example,dc=com</li>
<li>The password for the initial bind is joepassword</li>
</ul>
<p>The LDAP URL in the Cumin configuration file would like like this:</p>
<pre><code>auth: ldap://example.com:389/ou=People,dc=example,dc=com??sub?(&(uid=%%s))?bindname=uid=joeuser%%2cou=People%%2cdc=example%%2cdc=com,X-BINDPW=joespassword
</code></pre>
<p>Note in particular the %%2c substrings in the URL. These are the commas in the bindname value. In the interest of full disclosure, let me be the first to say “yuck”. But it works!</p>
<h3>Caution!</h3>
<p>LDAP credentials specified as part of a URL in the cumin configuration file will be visible to anyone who has access to the configuration file. When Cumin is installed as a package the configuration file will be located at <code>/etc/cumin/cumin.conf</code> and will only be readable by the <code>cumin</code> user. This should be adequate to protect the credentials as long as the permissions on that file are not changed.</p>
<p>However, if Cumin is run from sources in a development instance, alternate configuration files are possible. Care should be taken to protect those configuration files if they contain credentials.</p>
<p>The Cumin project wiki can be found <a href="http://fedorahosted.org/grid/wiki/Cumin">here</a></p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Integrating Cumin with LDAP for Authentication]]></title>
<link href="http://tmckayus.github.com/blog/2012/09/24/ldap-auth/"/>
<updated>2012-09-24T12:41:00-04:00</updated>
<id>http://tmckayus.github.com/blog/2012/09/24/ldap-auth</id>
<content type="html"><![CDATA[<p>Past versions of Cumin have relied on a local database for storing user accounts. However, that solution adds extra maintenance for site administrators who already have or plan to have a central authentication mechanism for their users. Consequently, development is ongoing to integrate Cumin with common central auth mechanisms. LDAP integration is available now, with support for other technologies planned for the future.</p>
<h3>How will central authentication work with Cumin?</h3>
<p>Let’s call an instance of a supported authentication scheme an “authenticator”. The PostgreSQL database installed with Cumin is the default authenticator – it will always be checked first whenever Cumin attempts to authenticate a user. If Cumin cannot authenticate the user via PostgreSQL, it will try other authenticators (i.e., LDAP repositories) specified in the cumin configuration file in listed order until the user is authenticated or the list of authenticators is exhausted.</p>
<h4>A current limitation</h4>
<p>There is one limitation in the initial LDAP support which makes the PostgreSQL user database indispensable: username and password may be specified in an LDAP repository, but the user role value can only explicitly be set in the PostgreSQL database (roles will be covered further in another blog post). This means that the <code>admin</code> role must be applied to users in the local database via the <code>cumin-admin</code> script. Non-admin users will default to the <code>user</code> role and no such entry will be needed. In the future, support for role values in LDAP is planned and local entries for admins will not be necessary.</p>
<h3>Miscellaneous Benefits, Implications, and Warnings</h3>
<ul>
<li><p>The local PostgreSQL user database may be very sparsely populated, containing only admin role assignments for certain users. If a site has few Cumin administrators or uses a single shared administration account, overhead for managing the PostgreSQL user database will be very low indeed.</p></li>
<li><p>An entry for a user may be made in the PostgreSQL database at any time to occlude any and all LDAP repository entries for that user. Using this feature, an admin could override a password to lock out a particular account or diagnose problems within that account, etc.</p></li>
<li><p>Multiple LDAP repositories may be specified as authenticators, and the same repository may be specified multiple times with different search criteria. This allows the same user to be authenticated by alternative servers or different criteria in priority order.</p></li>
<li><p>Cumin supports LDAP connections over SSL as well as SSL between the browser and the web server. In order for LDAP passwords to remain secure, SSL <strong><em>must be</em></strong> used on both network legs.</p></li>
</ul>
<h6>Documentation</h6>
<p>The <a href="http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/index.html">Management Console Installation Guide</a> contains everything you need to know to configure Cumin for LDAP authentication.</p>
<p> Here is a link to the <a href="http://fedorahosted.org/grid/wiki/Cumin">Cumin project wiki</a></p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[So What is Cumin Anyway?]]></title>
<link href="http://tmckayus.github.com/blog/2012/09/24/new-post/"/>
<updated>2012-09-24T12:07:00-04:00</updated>
<id>http://tmckayus.github.com/blog/2012/09/24/new-post</id>
<content type="html"><![CDATA[<p>Cumin is a Python web UI developed in the Fedora community for managing Condor pools and Qpid messaging brokers. It is packaged for Fedora but may be run from sources and would probably be easy to port to other Linux distributions (or just run Fedora on a node or two in a heterogeneous environment!) The current development focus for Cumin is on expanding the Condor management facilities.</p>
<h3>Condor Management Facilities</h3>
<p>Cumin is designed to meet the needs of a variety of Condor users. Non-admin end users are given a streamlined interface to create and manage their own submissions. The administrative views allow System Admins to monitor pool resources and Condor infrastructure while Operational Admins may be more interested in the workload running on the pool. Cumin has development hooks which make it possible to create customized presentations for different user and site profiles.</p>
<h3>Qpid Management Facilities</h3>
<p>Cumin’s Qpid messaging views allow management of a Qpid deployment. Users have visibility to message queues, exchanges, connections, and broker links. Many of the tasks that can be done from the Qpid command line tools can also be done through Cumin.</p>
<h3>How to Get Started</h3>
<p><a href="http://fedorahosted.org/grid/wiki/Cumin" title="http://fedorahosted.org/grid/wiki/Cumin">The Cumin project wiki</a> can be found <a href="http://fedorahosted.org/grid/wiki/Cumin" title="http://fedorahosted.org/grid/wiki/Cumin">here</a>, including user and developer mailing lists, install guides, and links to documentation. If you have any questions or comments, please do not hesitate to hit the Cumin mailing lists!</p>
]]></content>
</entry>
</feed>