The administrators for managing the system. To manage the administrators use the command pi-manage.py.
In addition certain realms can be defined to be administrative realms.
Parameters: |
|
---|
The table “caconnector” contains the names and types of the defined CA connectors. Each connector has a different configuration, that is stored in the table “caconnectorconfig”.
Each CAConnector can have multiple configuration entries. Each CA Connector type can have different required config values. Therefor the configuration is stored in simple key/value pairs. If the type of a config entry is set to “password” the value of this config entry is stored encrypted.
The config entries are referenced by the id of the resolver.
Table for handling of the generic challenges.
return a dictionary of all vars in the challenge class
Parameters: | timestamp (bool) – if true, the timestamp will given in a readable format 2014-11-29 21:56:43.057293 |
---|---|
Returns: | dict of vars |
This returns how many OTPs were already received for this challenge. and if a valid OTP was received.
Returns: | tuple of count and True/False |
---|---|
Return type: | tuple |
The config table holds all the system configuration in key value pairs.
Additional configuration for realms, resolvers and machine resolvers is stored in specific tables.
This model holds the definition to the machinestore. Machines could be located in flat files, LDAP directory or in puppet services or other...
The usual MachineResolver just holds a name and a type and a reference to its config
Each Machine Resolver can have multiple configuration entries. The config entries are referenced by the id of the machine resolver
The MachineToken assigns a Token and an application type to a machine. The Machine is represented as the tuple of machineresolver.id and the machine_id. The machine_id is defined by the machineresolver.
This can be an n:m mapping.
This class holds an Option for the token assigned to a certain client machine. Each Token-Clientmachine-Combination can have several options.
This class mixes in some common Class table functions like delete and save
The policy table contains policy definitions which control the behaviour during
- enrollment
- authentication
- authorization
- administration
- user actions
The realm table contains the defined realms. User Resolvers can be grouped to realms. This very table contains just contains the names of the realms. The linking to resolvers is stored in the table “resolverrealm”.
The table “resolver” contains the names and types of the defined User Resolvers. As each Resolver can have different required config values the configuration of the resolvers is stored in the table “resolverconfig”.
Each Resolver can have multiple configuration entries. Each Resolver type can have different required config values. Therefor the configuration is stored in simple key/value pairs. If the type of a config entry is set to “password” the value of this config entry is stored encrypted.
The config entries are referenced by the id of the resolver.
This table stores which Resolver is located in which realm This is a N:M relation
while the table “tokeninfo” contains additional information that is specific to the tokentype.
Deletes tokeninfo for a given token. If the key is omitted, all Tokeninfo is deleted.
Parameters: | key – searches for the given key to delete the entry |
---|---|
Returns: |
simulate the dict behaviour to make challenge processing easier, as this will have to deal as well with ‘dict only challenges’
Parameters: |
|
---|
calculate a hash from a pin Fix for working with MS SQL servers MS SQL servers sometimes return a ‘<space>’ when the column is empty: ‘’
Set the additional token info for this token
Entries that end with ”.type” are used as type for the keys. I.e. two entries sshkey=”XYZ” and sshkey.type=”password” will store the key sshkey as type “password”.
Parameters: | info (dict) – The key-values to set for this token |
---|
Set the list of the realms. This is done by filling the tokenrealm table. :param realms: realms :type realms: list
For smartcards this sets the security officer pin of the token
:rtype : None
The password is split into the PIN and the OTP component. THe token knows its length, so it can split accordingly.
Parameters: |
|
---|---|
Returns: | tuple of (res, pin, otpval) |
The table “tokeninfo” is used to store additional, long information that is specific to the tokentype. E.g. the tokentype “TOTP” has additional entries in the tokeninfo table for “timeStep” and “timeWindow”, which are stored in the column “Key” and “Value”.
The tokeninfo is reference by the foraign key to the “token” table.
This table stored to wich realms a token is assigned. A token is in the realm of the user it is assigned to. But a token can also be put into many additional realms.
Produce a conjunction of expressions joined by AND.
E.g.:
from sqlalchemy import and_
stmt = select([users_table]).where(
and_(
users_table.c.name == 'wendy',
users_table.c.enrolled == True
)
)
The and_() conjunction is also available using the Python & operator (though note that compound expressions need to be parenthesized in order to function with Python operator precedence behavior):
stmt = select([users_table]).where(
(users_table.c.name == 'wendy') &
(users_table.c.enrolled == True)
)
The and_() operation is also implicit in some cases; the Select.where() method for example can be invoked multiple times against a statement, which will have the effect of each clause being combined using and_():
stmt = select([users_table]).\
where(users_table.c.name == 'wendy').\
where(users_table.c.enrolled == True)
See also
or_()
Delete all challenges, that have expired.
Returns: | None |
---|
Return the database ID of the machine resolver :param resolvername: :return:
Returns the ID in the machinetoken table
Parameters: |
|
---|---|
Returns: | The ID of the machinetoken entry |
Return type: | int |