/
isis-security.xml
620 lines (463 loc) · 23.1 KB
/
isis-security.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
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
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"file:./src/docbkx/dtd-4.5/docbookx.dtd">
<book>
<bookinfo>
<title><?eval ${docbkxGuideTitle}?></title>
<subtitle><?eval ${docbkxGuideSubTitle}?></subtitle>
<releaseinfo><?eval ${project.version}?></releaseinfo>
<authorgroup>
<author>
<firstname>Robert</firstname>
<surname>Matthews</surname>
</author>
<author>
<firstname>Dan Haywood</firstname>
</author>
</authorgroup>
<legalnotice>
<para>Permission is granted to make and distribute verbatim copies of
this manual provided that the copyright notice and this permission
notice are preserved on all copies.</para>
</legalnotice>
</bookinfo>
<!-- front matter -->
<toc></toc>
<preface id="preface">
<title>Preface</title>
<para><emphasis>Apache Isis</emphasis> is designed to allow programmers
rapidly develop domain-driven applications following the <ulink
url="http://en.wikipedia.org/wiki/Naked_Objects">Naked Objects</ulink>
pattern. It is made up of a core framework that supports supports various
viewers, along with <acronym>API</acronym>s and implementations relating
to security, the programming model, the runtime (persistence) and profile
stores (user preferences). <emphasis>Apache Isis</emphasis> is hosted at
the <ulink url="http://incubator.apache.org/isis">Apache
Foundation</ulink>, and is licensed under <ulink
url="http://www.apache.org/licenses/LICENSE-2.0.html">Apache Software
License v2</ulink>.</para>
<para>The security <acronym>API</acronym> covers authentication and
authorization. A number of different security implementations, and this
guide explains how to configure them, as well as how to go about
implementing your own implementation.</para>
<sect1>
<title>Who this Guide is For</title>
<para>This guide is written for deployers looking to configure
<emphasis>Isis</emphasis> to run with a specific existing security
implementation, and for programmers wishing to develop their own custom
implementation. It is divided into the following parts:<itemizedlist>
<listitem>
<para>Isis Security Implementations</para>
<para>This part of the guide (see <xref
linkend="prt.IsisImplementations" />) covers the default (Java 5)
programming model, how to customize it, and how to extend
it.</para>
</listitem>
<listitem>
<para>Writing a Custom Implementation</para>
<para>This part of the guide (see <xref
linkend="prt.ImplementingACustomImplementation" />) describes how
to go about writing your own custom implementation of the security
<acronym>API</acronym>.</para>
</listitem>
<listitem>
<para>Configuring the Runtime</para>
<para>This part of the guide (see <xref
linkend="prt.ConfiguringTheRuntime" />) describes how to configure
your application to use a specified security
implementation.</para>
</listitem>
</itemizedlist></para>
</sect1>
<sect1>
<title>How this Guide relates to other Documentation</title>
<para>The <emphasis>core</emphasis> documentation
<package>[oai:core]</package> describes the security
<acronym>API</acronym> as defined by the <emphasis>core
runtime</emphasis> <package>[oai.core:runtime]</package>. The runtime
documentation (for example the <emphasis>default runtime</emphasis>
module <package>[oai.runtimes:dflt]</package>) will describe how to
configure security, but for convenience the configuration information is
also provided in this guide also.</para>
</sect1>
</preface>
<part id="prt.IsisImplementations">
<title>Isis Security Implementations</title>
<partintro>
<para><emphasis>Apache Isis</emphasis> applications support
authentication ("who are you"?) and authorization ("what can you do?").
This allows the set of functionality to be restricted based upon the
user's role, with no security knowledge needing to be embedded within
the domain objects. </para>
<para>From the domain objects persepective the user is represented as
the <classname>UserMemento</classname> and
<classname>RoleMemento</classname> values (in the
<package>oai.applib.security</package> package), but within the
framework the user is represented by an
<classname>AuthenticationSession</classname> object. From this session
object can be obtained the name of the user and their roles.</para>
<para>The security <acronym>API</acronym> is defined in the
<emphasis>core runtime</emphasis> module [oai.core:runtime] by the
<classname>AuthenticationManager</classname> interface and the
<classname>AuthorizationManager</classname> interface. Isis has a number
of implementations of both: a default (no-op) implementation, a simple
file-based implementation and an <acronym>LDAP</acronym> implementation.
The default for the authentication manager depends on the runtime;
</para>
<para>If no authorization manager has been specified, then all domain
properties, collections and actions will be available to all users. When
an authorization manager is configured, it can be used to authorise the
visibility ("can you see it?") and usability ("can you use it?") of
properties/collections and actions independently. This is done with
respect to the roles that are assigned to the user. Thus an object
member may be visible to certain roles but not editable.</para>
<para>It is possible, if required, to mix-and-match implementations. For
example, authentication could be using LDAP, but authorization could be
done using file-based implementation or a custom implementation.</para>
</partintro>
<chapter>
<title>Default (No-op) Security Implementation</title>
<abstract>
<para>*** yada yada</para>
</abstract>
<sect1>
<title>***</title>
<para><emphasis>*** yada yada</emphasis></para>
</sect1>
</chapter>
<chapter id="chp.FileIntro">
<title>File Security Implementation</title>
<abstract>
<para>A simple file-based security implementation that reads from
plain text files that reside in the configuration directory.</para>
</abstract>
<sect1>
<title>Authentication</title>
<para>Authentication grants access to users, and determines their
current roles.</para>
<sect2>
<title>The Passwords File</title>
<para>The file-based authenticator reads the user/passwords and
roles from a file called <filename class="directory"
moreinfo="none">security_file.password</filename>s. This should
reside in the same location as the
<emphasis>isis.properties</emphasis> configuration file.</para>
<para>The format of this file is:</para>
<programlisting format="linespecific"><user>:<password>:<role>|<role>|...</programlisting>
</sect2>
<sect2>
<title>Example</title>
<para>The following example shows how user names (sven and dick) and
corresponding passwords (passwd1 and passwd2) should be specified in
the password file.</para>
<programlisting format="linespecific">sven:passwd1:role1|role2
dick:passwd2:role3</programlisting>
<para>The user 'sven' has roles 'role1' and 'role2', while 'dick'
has 'role3'.</para>
</sect2>
</sect1>
<sect1>
<title>Authorization</title>
<para>Authorization allows access to actions and properties to be
controlled by configuration. </para>
<sect2>
<title>Authorization through 'allow' and 'disallow' files</title>
<para>With file authorization the current user's role will be
authorised against a white and (optionally) a black list for each
method possibly available to them. The files are identified by
properties, e.g.</para>
<programlisting format="linespecific">isis.authorization.file.whitelist=security_file.allow
isis.authorization.file.blacklist=security_file.disallow </programlisting>
<para>The white list file is mandatory, if there is no property it
defaults to <filename>security_file.allow</filename>, and is picked
up from the same location as the
<filename>isis.properties</filename> configuration file.</para>
<para>The black list file is optional; the presence of the property
indicates it is being used. If the white list file default is being
used then we recommend <filename>security_file.disallow</filename>
as the name of the black list file. Again, it is picked up from the
same location as <filename>isis.properties</filename> configuration
file.</para>
<para>The settings can then be modified to conform to the required
security settings.</para>
</sect2>
<sect2>
<title>Matching</title>
<para>Each file contains a signature to match against and a list of
roles, which follow the same <itemizedlist>
<listitem>
<para>A match in the white list file permits the access</para>
</listitem>
<listitem>
<para>A match in the black list forbids it the access</para>
</listitem>
<listitem>
<para>The black list overrides the white list</para>
</listitem>
</itemizedlist></para>
<para>Matching occurs at three levels class, method (or property)
and parameters</para>
<para>Property matches are to the bean property name e.g. 'phone'
for getPhone and setPhone.</para>
</sect2>
<sect2>
<title>File Format</title>
<para>The files are formatted as follows:</para>
<itemizedlist>
<listitem>
<para>If only class is to be matched: </para>
<para><programlisting><fully qualified class> :role1|role2|..</programlisting></para>
</listitem>
<listitem>
<para>If class and method matched: </para>
<programlisting><fully qualified class>#<method>:role1|role2|..</programlisting>
</listitem>
<listitem>
<para>If class and property/collection matched:</para>
<programlisting><fully qualified class>#<property>:role1|role2|..</programlisting>
</listitem>
<listitem>
<para>If action where method takes no parameters: </para>
<programlisting><fully qualified class>#<method>():role1|role2|...</programlisting>
</listitem>
<listitem>
<para>If action where method takes one parameter: </para>
<programlisting><fully qualified class>#<method>(fully qualified parameter class):role1|role2|...</programlisting>
</listitem>
<listitem>
<para>If action where method takes two or more
parameters:<programlisting><fully qualified class>#<method>(fully qualified parameter class1, fully qualified parameter class2, ...):role1|role2|...</programlisting></para>
</listitem>
</itemizedlist>
<para>Each line in the file is a separate match.</para>
<para>There is an optional capability to authorise the visibility
and usability of fields independently. Thus a field may be visible
to certain roles but not editable. In order to configure this
against a authorization a qualifier is added to the role, either
"-ro" for read-only (visible) or "-rw" for read/write (visible and
usable). For example:</para>
<programlisting><fully qualified class> :role1-ro|role2-rw|..</programlisting>
</sect2>
<sect2>
<title>Example</title>
<para>For example, if in the white list file we have:</para>
<programlisting format="linespecific">org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDflt:role1 </programlisting>
<para>then this will permit all actions/properties on <literal
moreinfo="none">org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDflt</literal>
for role1 to invoke.</para>
<para>Meanwhile, if we have:</para>
<programlisting format="linespecific">org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDflt#findClaimantByName:role1-ro|role2-rw</programlisting>
<para>then this will permit all overloaded methods named <literal
moreinfo="none">findClaimantByName</literal> on <literal
moreinfo="none">org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDflt</literal>
for role1 to view, and for role2 to view and also invoke</para>
<para>Finally, if we have:</para>
<programlisting format="linespecific">org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDflt#findClaimantByIdentifier(java.lang.String):role3-rw</programlisting>
<para>then this will permit <literal
moreinfo="none">findClaimantByIdentifier</literal> with parameter
<literal moreinfo="none">java.lang.String</literal> on <literal
moreinfo="none">org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDflt</literal>
for role3 to invoke.</para>
<para>In each case an identical entry in the black list file will
instead make the action or property unavailable. </para>
<para>The combination of white and black list allows some economy in
the settings. For example, if all but one method of a large class is
to be allowed, that could be configured with one entry per method in
the white list file or, better, a single entry for the class in the
white list and a single entry for the unavailable method in the
black list.</para>
</sect2>
<sect2>
<title>Auto-learn</title>
<para>As a tool for helping to configure the initial security
settings there is a 'learn' property.</para>
<programlisting format="linespecific">isis.authorization.learn=true</programlisting>
<para>When this is present and set, all methods will be authorised
for all roles. However as each method is accessed through the user
interface authorization will be configured for that method and the
current role. The idea is to these files can then be used as the
basis for explicit configuration once auto-learn is disabled.</para>
</sect2>
</sect1>
</chapter>
<chapter>
<title>LDAP Security Implementation</title>
<abstract>
<para>*** yada yada</para>
</abstract>
<sect1>
<title>Authentication</title>
<para>LDAP needs a URL for the server and a 'dn' of the root of the
users on the server. For example,</para>
<programlisting format="linespecific">isis.authentication.ldap.dn= dc=isis, dc=org </programlisting>
<programlisting format="linespecific">isis.authentication.ldap.server=ldap://localhost:10389</programlisting>
<para>The logon password check will be on uid='username', <dn>
-</para>
<para>For example, attempting to logon with user 'sven' with the above
settings will check against the server on localhost, port = 10389,
uid=sven, dc=isis, dc=org, using the password in the standard <literal
moreinfo="none">userpassword</literal> attribute in that entry. Once
logged in, roles will be picked up from cn='rolename' where
objectclass =organizationalRole in child entries of the user
entry.</para>
</sect1>
<sect1>
<title>Authorization</title>
<para>With LDAP authorization the current user's role will be
authorised against an entry in the LDAP server for each method
possibly available to them. The URL of the server is obtained from the
same property as for authentication.</para>
<para>The authorization entries should exist under a DN configured in
the property file. For example.</para>
<programlisting format="linespecific">isis.authorization.ldap.application.dn= cn=expenses, dc=apps, dc=isis, dc=org </programlisting>
<para>This will be checked anonymously.</para>
<para>Entries to be matched against should exist under this dn.
Expected configuration is a hierarchy of class, method and parameters.
The cn of each entry is expected to be the fully qualified class name,
method or parameter list ('()' for an empty parameter list). If an
entry has a 'uniquemember' attribute equal to 'role' then that entry
and all sub-entries are authorised.</para>
<para>For example:</para>
<itemizedlist>
<listitem>
<para>DN:
cn=org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDefault,
cn=expenses, dc=apps, dc=isis, dc=org</para>
<para>with uniquemember = role1</para>
<para>will authorise all members of <literal
moreinfo="none">org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDefault</literal>
for users with role1.</para>
</listitem>
<listitem>
<para>DN: cn=(org.apache.isis.expenses.claims.Claimant,
java.lang.String), cn=createNewClaim,
cn=org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDefault,
cn=expenses, dc=apps, dc=isis, dc=org</para>
<para>with uniquemember = role1</para>
<para>will authorise the <literal
moreinfo="none">createNewClaim(org.apache.isis.expenses.claims.Claimant,
String)</literal> member of <literal
moreinfo="none">org.apache.isis.expenses.claims.objstoredflt.ClaimRepositoryDefault</literal>
for users with role1.</para>
</listitem>
</itemizedlist>
<para>There is an optional capability to authorise the visibility and
usability of fields independently. Thus a field may be visible to
certain roles but not editable. In order to configure this against a
authorization a flag must be added by setting a "flags" attribute to
the entry with the role. <itemizedlist>
<listitem>
<para>If it is set to 'rw' then editing will be allowed,</para>
</listitem>
<listitem>
<para>If it is set to any other value (typically 'ro') then
editing is disallowed</para>
</listitem>
</itemizedlist></para>
<para>In each case absence of the flag will mean that visibility and
usability and are always the same.</para>
</sect1>
</chapter>
</part>
<part id="prt.ConfiguringTheRuntime">
<title>Configuring the Runtime</title>
<partintro>
<para>***</para>
<para></para>
</partintro>
<chapter>
<title>Configuring the Default Runtime</title>
<abstract>
<para>*** yada yada</para>
</abstract>
<para></para>
<sect1>
<title>Exploration Mode</title>
<para>The list of users that can be switched between during
exploration can be listed, separated by commas, using:</para>
<programlisting format="linespecific">isis.exploration.users=sven, dick, bob</programlisting>
<para>If no users are specified the default user "exploration" will be
used and switching between users will not be possible.</para>
<para><note>
<para>The ability to switch between users also depends on the
viewer being used; not every viewer has necessarily implemented
this feature.</para>
</note></para>
</sect1>
<sect1>
<title>No Configuration</title>
<para></para>
<para>If no authenticator is configured, then the behaviour depends on
the system:</para>
<itemizedlist>
<listitem>
<para>Exploration Mode</para>
<para>*** yada yada</para>
</listitem>
<listitem>
<para>Prototype Mode</para>
<para>*** yada yada</para>
</listitem>
<listitem>
<para>Any other mode</para>
<para>Defaults to file-based</para>
</listitem>
</itemizedlist>
<para></para>
</sect1>
<sect1>
<title>Configuring Authentication</title>
<para></para>
<para>To explicitly use file-based authentication set the following
property.</para>
<programlisting format="linespecific">isis.authentication=file</programlisting>
<para></para>
<para>To authenticate through LDAP set</para>
<programlisting format="linespecific">isis.authentication=ldap</programlisting>
<para></para>
</sect1>
<sect1>
<title>Configuring Authorization</title>
<para></para>
<para>To enable authorization within the default runtime, including
the facet and specifying the authorization implementation in the
settings</para>
<programlisting format="linespecific">isis.reflector.facets.include=\
org.apache.isis.core.runtime.authorization.standard.AuthorizationFacetFactory
</programlisting>
<para></para>
<para>To specify file-based authorization, use:</para>
<programlisting format="linespecific">isis.authorization=file</programlisting>
<para></para>
<para>To specify LDAP-based authorization, use:</para>
<programlisting format="linespecific">isis.authorization=ldap</programlisting>
</sect1>
</chapter>
</part>
<part id="prt.ImplementingACustomImplementation">
<title>Implementing a custom Security Implementation</title>
<chapter>
<title></title>
<section>
<title></title>
<para></para>
</section>
</chapter>
</part>
</book>