3
3
Configuration of pySAML2 entities
4
4
=================================
5
5
6
- Whether you plan to run a pySAML2 Service Provider, Identity provider or an
6
+ Whether you plan to run a pySAML2 Service Provider, Identity Provider or an
7
7
attribute authority you have to configure it. The format of the configuration
8
- file is the same disregarding which type of service you plan to run.
9
- What differs is some of the directives.
10
- Below you will find a list of all the used directives in alphabetic order.
8
+ file is the same regardless of which type of service you plan to run.
9
+ What differs are some of the directives.
10
+ Below you will find a list of all the used directives in alphabetical order.
11
11
The configuration is written as a python module which contains a named
12
12
dictionary ("CONFIG") that contains the configuration directives.
13
13
14
- The basic structure of the configuration file is therefor like this::
14
+ The basic structure of the configuration file is therefore like this::
15
15
16
16
from saml2 import BINDING_HTTP_REDIRECT
17
17
@@ -90,9 +90,9 @@ The attribute map module contains a MAP dictionary with three items. The
90
90
The *to * and *fro * sub-dictionaries then contain the mapping between the names.
91
91
92
92
As you see the format is again a python dictionary where the key is the
93
- name to convert from and the value is the name to convert to.
93
+ name to convert from, and the value is the name to convert to.
94
94
95
- Since *to * in most cases are the inverse of the *fro * file, the
95
+ Since *to * in most cases is the inverse of the *fro * file, the
96
96
software allowes you to only specify one of them and it will
97
97
automatically create the other.
98
98
@@ -111,7 +111,7 @@ contact_person
111
111
112
112
This is only used by *make_metadata.py * when it constructs the metadata for
113
113
the service described by the configuration file.
114
- This is where you described who can be contacted if questions arises
114
+ This is where you describe who can be contacted if questions arise
115
115
about the service or if support is needed. The possible types are according to
116
116
the standard **technical **, **support **, **administrative **, **billing **
117
117
and **other **.::
@@ -148,7 +148,7 @@ Format::
148
148
149
149
The globally unique identifier of the entity.
150
150
151
- .. note :: There is a recommendation that the entityid should point to a real
151
+ .. note :: It is recommended that the entityid should point to a real
152
152
webpage where the metadata for the entity can be found.
153
153
154
154
key_file
@@ -160,13 +160,13 @@ Format::
160
160
161
161
*key_file * is the name of a PEM formatted file that contains the private key
162
162
of the service. This is presently used both to encrypt/sign assertions and as
163
- client key in a HTTPS session.
163
+ the client key in an HTTPS session.
164
164
165
165
metadata
166
166
^^^^^^^^
167
167
168
168
Contains a list of places where metadata can be found. This can be either
169
- a file accessible on the server the service runs on or somewhere on the net.::
169
+ a file accessible on the server the service runs on, or somewhere on the net.::
170
170
171
171
"metadata" : {
172
172
"local": [
@@ -180,8 +180,8 @@ a file accessible on the server the service runs on or somewhere on the net.::
180
180
},
181
181
182
182
The above configuration means that the service should read two local
183
- metadata files and on top of that load one from the net. To verify the
184
- authenticity of the file downloaded from the net the local copy of the
183
+ metadata files, and on top of that load one from the net. To verify the
184
+ authenticity of the file downloaded from the net, the local copy of the
185
185
public key should be used.
186
186
This public key must be acquired by some out-of-band method.
187
187
@@ -205,7 +205,7 @@ Where you describe the organization responsible for the service.::
205
205
service
206
206
^^^^^^^
207
207
208
- Which services the server will provide, those are combinations of "idp","sp"
208
+ Which services the server will provide; those are combinations of "idp", "sp"
209
209
and "aa".
210
210
So if a server is a Service Provider (SP) then the configuration
211
211
could look something like this::
@@ -228,13 +228,13 @@ could look something like this::
228
228
229
229
There are two options common to all services: 'name' and 'endpoints'.
230
230
The remaining options are specific to one or the other of the service types.
231
- Which one is specified along side the name of the option
231
+ Which one is specified along side the name of the option.
232
232
233
233
timeslack
234
234
^^^^^^^^^
235
235
236
236
If your computer and another computer that you are communicating with are not
237
- in synch regarding the computer clock. Then you here can state how big a
237
+ in synch regarding the computer clock, then here you can state how big a
238
238
difference you are prepared to accept.
239
239
240
240
.. note :: This will indiscriminately effect all time comparisons.
@@ -275,7 +275,7 @@ policy
275
275
276
276
If the server is an IdP and/or an AA then there might be reasons to do things
277
277
differently depending on who is asking; this is where that is specified.
278
- The keys are 'default' and SP entity identifiers, default is used whenever
278
+ The keys are 'default' and SP entity identifiers. Default is used whenever
279
279
there is no entry for a specific SP. The reasoning is also that if there is
280
280
no default and only SP entity identifiers as keys, then the server will only
281
281
except connections from the specified SPs.
@@ -301,12 +301,12 @@ An example might be::
301
301
}
302
302
303
303
*lifetime *
304
- is the maximum amount of time before the information should be
304
+ This is the maximum amount of time before the information should be
305
305
regarded as stale. In an Assertion this is represented in the NotOnOrAfter
306
306
attribute.
307
307
*attribute_restrictions *
308
308
By default there is no restrictions as to which attributes should be
309
- return. Instead all the attributes and values that is gathered by the
309
+ return. Instead all the attributes and values that are gathered by the
310
310
database backends will be returned if nothing else is stated.
311
311
In the example above the SP with the entity identifier
312
312
"urn:mace: umu.se:saml: roland:sp"
@@ -332,7 +332,7 @@ regular expressions.::
332
332
}
333
333
}
334
334
335
- Here only mail addresses that ends with ".umu.se" will be returned.
335
+ Here only mail addresses that end with ".umu.se" will be returned.
336
336
337
337
sp
338
338
^^
@@ -345,7 +345,7 @@ authn_requests_signed
345
345
Indicates if the Authentication Requests sent by this SP should be signed
346
346
by default. This can be overriden by application code for a specific call.
347
347
348
- This set the AuthnRequestsSigned attribute of the SPSSODescriptor node.
348
+ This sets the AuthnRequestsSigned attribute of the SPSSODescriptor node
349
349
of the metadata so the IdP will know this SP preference.
350
350
351
351
Valid values are "true" or "false". Default value is "false".
@@ -362,9 +362,9 @@ Example::
362
362
idp
363
363
"""
364
364
365
- Defines the set of IdPs that this SP is allowed to use. If not all the IdPs in
366
- the metadata is allowed , then the value is expected to be a list with entity
367
- identifiers for the allowed IdPs.
365
+ Defines the set of IdPs that this SP is allowed to use; if unset, all listed
366
+ IdPs may be used. If set , then the value is expected to be a list with entity
367
+ identifiers for the allowed IdPs.
368
368
A typical configuration, when the allowed set of IdPs are limited, would look
369
369
something like this::
370
370
@@ -376,8 +376,6 @@ something like this::
376
376
377
377
In this case the SP has only one IdP it can use.
378
378
379
- If all IdPs present in the metadata loaded this directive must be left out.
380
-
381
379
optional_attributes
382
380
"""""""""""""""""""
383
381
@@ -415,7 +413,7 @@ want_assertions_signed
415
413
""""""""""""""""""""""
416
414
417
415
Indicates if this SP wants the IdP to send the assertions signed. This
418
- set the WantAssertionsSigned attribute of the SPSSODescriptor node.
416
+ sets the WantAssertionsSigned attribute of the SPSSODescriptor node
419
417
of the metadata so the IdP will know this SP preference.
420
418
421
419
Valid values are "true" or "false". Default value is "true".
@@ -440,7 +438,7 @@ endpoints
440
438
"""""""""
441
439
442
440
Where the endpoints for the services provided are.
443
- This directive has as value a dictionary with one of the following keys:
441
+ This directive has as value a dictionary with one or more of the following keys:
444
442
445
443
* artifact_resolution_service (aa, idp and sp)
446
444
* assertion_consumer_service (sp)
@@ -474,7 +472,7 @@ Indicates if this entity will sign the Logout Requests originated from it.
474
472
475
473
This can be overriden by application code for a specific call.
476
474
477
- Valid values are "true" or "false". Default value is "false"
475
+ Valid values are "true" or "false". Default value is "false".
478
476
479
477
Example::
480
478
@@ -491,7 +489,7 @@ The name of a database where the map between a local identifier and
491
489
a distributed identifier is kept. By default this is a shelve database.
492
490
So if you just specify name, then a shelve database with that name
493
491
is created. On the other hand if you specify a tuple then the first
494
- element in the tuple specifise which type of database you want to use
492
+ element in the tuple specifies which type of database you want to use
495
493
and the second element is the address of the database.
496
494
497
495
Example::
@@ -519,7 +517,7 @@ Gives information about common identifiers for virtual_organizations::
519
517
},
520
518
521
519
Keys in this dictionary are the identifiers for the virtual organizations.
522
- The arguments per organization is 'nameid_format' and 'common_identifier'.
520
+ The arguments per organization are 'nameid_format' and 'common_identifier'.
523
521
Useful if all the IdPs and AAs that are involved in a virtual organization
524
522
have common attribute values for users that are part of the VO.
525
523
@@ -562,8 +560,8 @@ We start with a simple but fairly complete Service provider configuration::
562
560
}
563
561
564
562
This is the typical setup for a SP.
565
- A metadata file to load is *always * needed, but it can of course be
566
- containing anything from 1 up to many entity descriptions.
563
+ A metadata file to load is *always * needed, but it can of course
564
+ contain anything from 1 up to many entity descriptions.
567
565
568
566
------
569
567
0 commit comments