You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is important the `graphId` here matches the ID of the main graph you
131
-
wish to connect to as this controls which Accumulo table is connected to.
132
-
133
-
Many of these properties in the example above should be self explanatory, a full breakdown of
134
-
of the available properties is as follows:
135
-
136
-
| Property Key | Description |
137
-
| --- | --- |
138
-
|`gremlin.graph`| The Tinkerpop graph class we should use |
139
-
|`gaffer.graphId`| The graph ID of the Tinkerpop graph |
140
-
|`gaffer.storeproperties`| The path to the store properties file |
141
-
|`gaffer.schemas`| The path to the directory containing the graph schema files |
142
-
|`gaffer.userId`| The default user ID for the Tinkerpop graph (see the [authentication section](#user-authentication)) |
143
-
|`gaffer.dataAuths`| The default data auths for the user to specify what operations can be performed |
144
-
|`gaffer.operation.options`| Default `Operation` options in the form `key:value` (this can be overridden per query see [here](../../user-guide/query/gremlin/gremlin.md#custom-features)) |
145
-
146
-
### Configuring the Gremlin Server
147
-
148
-
The underlying Gremlin server can also be configured if required. The `gaffer-gremlin`
149
-
image comes with an existing YAML configuration based on the example from the
The `authorizer` should always be the `GafferPopAuthoriser` as this is what
196
-
handles denying invalid queries for GafferPop and passing the user on to the
197
-
Gaffer graph for fine grained security.
74
+
A full breakdown of the available properties is as follows:
198
75
199
76
!!! note
200
-
The `GafferPopAuthoriser` will deny attempts to set the user ID via a
201
-
`with("userId", <id>)`step in the Gremlin query.
202
-
203
-
The `authenticator` should be a class specific to the auth mechanism for your
204
-
deployment e.g. LDAP. An example class `ExampleGafferPopAuthenticator` is
205
-
provided as a start point but does not do any actual authenticating so should
206
-
**not** be used in production.
207
-
208
-
!!! tip
209
-
Tinkerpop provides some implementaions of `Authenticators` for standard
210
-
mechanisms such as [Kerberos](https://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/server/auth/Krb5Authenticator.html).
211
-
Please see the [Tinkerpop documentation](https://tinkerpop.apache.org/docs/current/reference/#security) for more info.
77
+
Many of these are for standalone GafferPop Graphs so may be ignored if using
78
+
the REST API.
79
+
80
+
| Property Key | Description | Used in REST API |
81
+
| --- | --- | --- |
82
+
|`gremlin.graph`| The Tinkerpop graph class we should use for construction. | No |
83
+
|`gaffer.graphId`| The graph ID of the Tinkerpop graph. | No |
84
+
|`gaffer.storeproperties`| The path to the store properties file. | No |
85
+
|`gaffer.schemas`| The path to the directory containing the graph schema files. | No |
86
+
|`gaffer.userId`| The default user ID for the Tinkerpop graph. | No (User is always set via the [`UserFactory`](../security/user-control.md).) |
87
+
|`gaffer.dataAuths`| The default data auths for the user to specify what operations can be performed | No |
88
+
|`gaffer.operation.options`| Default `Operation` options in the form `key:value` (this can be overridden per query see [here](../../user-guide/query/gremlin/custom-features.md)) | Yes |
89
+
|`gaffer.elements.getalllimit`| The default limit for unseeded queries e.g. `g.V()`. | Yes |
90
+
|`gaffer.elements.hasstepfilterstage`| The default stage to apply any `has()` steps e.g. `PRE_AGGREGATION`| Yes |
The user authentication layer for Gaffer is currently only enforced by the REST
8
+
API. We recommend restricting users such that they do not have access to the
9
+
underlying Java API so that all queries are authenticated and executed via the
10
+
REST API.
11
+
12
+
In the REST API the `User` object is constructed via a [`UserFactory`](https://gchq.github.io/Gaffer/uk/gov/gchq/gaffer/rest/factory/UserFactory.html).
13
+
In the Spring REST API an abstract implementation of this class is used,
14
+
`AbstractUserFactory`, which is then used in the passing of HTTP headers for
15
+
authentication.
16
+
17
+
Currently, there is a single default implementation of this; the
18
+
`UnknownUserFactory` which simply returns a new `User` with `UNKNOWN` as the
19
+
user ID. To specify the user
20
+
factory class define the `gaffer.user.factory.class`[REST property](../gaffer-config/config.md#application-properties).
21
+
22
+
## Writing a User Factory
23
+
24
+
To authenticate your users you will need to extend the `AbstractUserFactory` class
25
+
to add your chosen authentication mechanism. The hooks will already be in the REST API
26
+
to pass the current HTTP headers for each request. Your factory will need to parse these
27
+
to construct a new `User` object via the `createUser()` method that reflects the user
28
+
making the request. This could involve making a call to an LDAP server or similar
29
+
authentication service.
30
+
31
+
For example, you could use the authorisation header in the request:
0 commit comments