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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
|
Stanford University Wallet Naming Conventions
Introduction
These are the naming conventions used at Stanford University for
wallet objects. They may not be appropriate for every site using
wallet, but they can serve as a starting point for your site-local
conventions. They are the conventions enforced by
examples/stanford.conf (to the extent it's possible to enforce them).
Object Naming
Keytab
Keytab object names correspond to the principal names in your Kerberos
database, so there's no need for a wallet-specific set of naming
conventions. Apply whatever conventions you apply to the names of
service principals in your KDC.
If you do not already have naming standards for service principals,
you may want to develop some as part of your wallet deployment. We
use the following:
* Per user principals for doing automated things related to an
individual user account are named as instances of the corresponding
user principal. For example, we manage CGI instances for users with
CGI service in the wallet and run CGI scripts with Kerberos tickets
and AFS tokens for that principal. If my account is rra, the CGI
instance is rra/cgi.
* Service principals for campus departments and groups are handled
similarly but start with dept- or group- prefixes respectively. If
there is a campus department named ITS, its CGI instance is
dept-its/cgi.
* Class principals start with class-, then the class code, the section
if relevant, and then the PeopleSoft quarter. So the class aa100,
section 01, in fall quarter of 2008 has a CGI principal named
class-aa100-01-1082/cgi.
* Host-based principals follow the standard naming convention in
Kerberos: service, followed by a slash, followed by the
fully-qualified hostname in all lowercase. For example, the webauth
service on windlord.stanford.edu is webauth/windlord.stanford.edu.
It's very useful to have wallet enforce fully-qualifying the
hostname and giving the hostname in all lowercase, since both are
common errors.
* Other, non-host-based principals that aren't tied to a particular
account and aren't CGI principals for a group, department, or class
have names like service/<service-name> where <service-name> is a
relatively short description of the service that ideally includes
some indication of the responsible department where appropriate. We
use - rather than _ as a separator between components of
<service-name>.
File
File objects pose the most significant challenge to naming since they
can contain just about anything. We require some discussion before
putting a new type of data into a wallet file object, both to see if
it should get its own object type first and to agree on a naming
convention for that type of thing.
All file object names start with a short indicator of the responsible
group, a slash, the type of object, a slash, and then the hostname (if
they're only used on a single host) or the service name for which that
object is used. The hostname is normally presented without the domain
if it's a normal .stanford.edu host.
We previously instead used <group>-<server>-<type>, but that caused
various problems in parsing because groups, servers, and types all
also contained dashes. Slashes are much less ambiguous. This
document shows both the new and the old form.
Then, we use the following naming conventions for different types of
objects.
Host-based:
<group>/htpasswd/<server>/<app>
An .htpasswd file for HTTP Basic Authentication for special-case
web configurations that require such a thing.
(OLD: <group>-<server>-htpasswd-<app>)
<group>/ssh-<type>/<server>
Stores the SSH private key for <server>. For shared private keys
across a pool, <server> should be the name of the pool, or
possibly some unambiguous name for the set of systems. <type> is
the type of SSH key (RSA or DSA).
(OLD: <group>-<server>-ssh-<type>)
<group>/ssl-key/<server>
Stores the SSL X.509 certificate private key for <server>. Used
for Apache, Postfix, LDAP, and similar cases where the certificate
should match the host name. The public certificate we manage
external to wallet since it doesn't need to be protected or
encrypted.
Use idg/ssl-key/starYYYY for the key for the *.stanford.edu
certificate, where YYYY is the expiration year.
(OLD: <group>-<server>-ssl-key)
<group>/tivoli-key/<server>
The Tivoli password or backup encryption key for this server.
Both the password and the encryption key, if used, are stored in
the same file, so both are stored together. This file is found at
/etc/adsm/TSM.PWD.
(OLD: <group>-<server>-tivoli-key)
In all cases, <server> is the server (or group of servers) on which
the file will be stored, not the server expecting that key material
for authentication.
Service-based:
<group>/config/<service>-<name>
A configuration file named <name> that contains some secure
information, such as a database password. Ideally, the secure
data should be stored in a separate file and assembled into the
configuration file. This is reserved for configuration files that
hold nothing but authentication information. Only use this naming
convention if there is not a more specific one below.
(OLD: <group>-<service>-config-<name>)
<group>/db/<service>/<database>
Stores the database password for <service> access to the database
named <database>. This may be a file containing only the database
password or a Perl AppConfig configuration file with the database
connection information including the password.
(OLD: <group>-<service>-db-<database>)
<group>/gpg-key/<service>
Stores the GnuPG private key for a service that needs to do GnuPG
signing or encryption.
(OLD: <group>-<service>-gpg-key)
<group>/password/<service>-<name>
A password for some account, service, keystore, or something
similar that covered by one of the more specific naming
conventions, such as a password used to connect to a remote ssh
service. <service> is the service that uses this password and
<name> is the thing the password is used for (such as the remote
account name). This may be a file containing only the password,
or a configuration file of some type that includes a field name
and the password. (However, use the db type described above for
database passwords.)
(OLD: <group>-<server>-password-<account>)
<group>/properties/<service>
The properties file for a Java application that contains some
secure data (such as SSL key passwords or database passwords).
This should only be used for a properties file that contains only
the password and closely-related information, such as database
connection information. For anything else, switch to storing the
password separately using the password type above and building the
properties file dynamically from the password and a template.
(OLD: <group>-<service>-properties)
<group>/ssl-keystore/<service>
The Java keystore file (containing both public and private key)
used by a service for authentication to other services. If a
given service uses more than one, include the purpose in the
<service> part of the name.
(OLD: <group>-<service>-ssl-keystore)
<group>/ssl-pkcs12/<service>
The PKCS#12 file (containing both public and private key) used by
a service for authentication to other services. If a given
service uses more than one, include the purpose in the <service>
part of the name.
(OLD: <group>-<service>-ssl-pkcs12)
We previously stored a wider variety of configuration files before
developing a way to dynamically substitute the password into a larger
configuration file during deployment. The following file types are
obsolete and should no longer be used; instead, the configuration file
should be constructed by substituting a password (usually stored as a
password or db type) into the configuration file.
Obsolete:
<group>-<server>-pam-<app>
<group>-<service>-puppetconf
<group>-<service>-shibboleth
ACL Naming
Currently, there is no naming enforcement for ACLs, so ACL naming has
to be done purely by policy. In a later version of wallet, there will
be support for enforcing ACL naming conventions.
We use the following conventions:
host/<host>
Any object that should be downloadable by either any administrator
of <host> or by the host key itself. An ACL named like this
should have as its contents either:
netdb example.stanford.edu
krb5 host/example.stanford.edu@stanford.edu
or:
netdb-root example.stanford.edu
krb5 host/example.stanford.edu@stanford.edu
Don't use this ACL name for ACLs with other content. Instead, use
one of the other ones below.
group/*
Groups of users. Each ACL line should probably have a scheme of
krb5 and an identifier of a Kerberos principal (which must include
the @stanford.edu portion). Eventually, wallet will support using
PTS groups and Workgroup Manager groups, but for right now this is
how groups are supported.
user/<username>
A keytab that's only downloadable by one particular person.
Double-check that a host/<host> ACL or a group/* ACL wouldn't be
more correct. If this is what's desired, it would have a single
line of scheme krb5 and identifier equal to the user's full
Kerberos principal.
service/<service>
Used for keytabs that should be downloadable by a service, as
opposed to a group of people. Usually this ACL will have lines
like krb5 service/<service>@stanford.edu to let the service
principal download other associated keytabs, but it may contain
other things as well, including administrators for that service so
that they can bootstrap or test. This naming convention should
also be used for ACLs that allow multiple hosts to download the
same object, such as:
netdb-root example.stanford.edu
krb5 host/example.stanford.edu@stanford.edu
netdb-root example-dev.stanford.edu
krb5 host/example-dev.stanford.edu@stanford.edu
Such an ACL would normally be named service/example.
|
