Merge pull request #204 from pedroigor/master

Group policy docs and minor fixes to summary
This commit is contained in:
Bill Burke 2017-10-03 09:09:44 -04:00 committed by GitHub
commit 5fafa8c3b3
11 changed files with 57 additions and 3 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 99 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

View file

@ -51,6 +51,10 @@ include::topics/policy/aggregated-policy.adoc[]
include::topics/policy/client-policy.adoc[]
include::topics/policy/group-policy.adoc[]
include::topics/policy/group-policy-extend-children.adoc[]
include::topics/policy/logic.adoc[]
include::topics/policy/evaluation-api.adoc[]

View file

@ -0,0 +1,12 @@
[[_policy_group_extend_access_children]]
==== Extending Access to Child Groups
By default, when you add a group to this policy, access restrictions will only apply to members of the selected group.
Under some circumstances, it might be necessary to allow access not only to the group itself but to any child group in the hierarchy. For any group
added you can mark a checkbox *Extend to Children* in order to extend access to child groups.
.Extending Access to Child Groups
image:{project_images}/policy/create-group-extend-children.png[alt="Extending Access to Child Groups"]
In the example above, the policy is granting access for any user member of *IT* or any of its children.

View file

@ -0,0 +1,35 @@
[[_policy_group]]
=== Group-Based Policy
You can use this type of policy to define conditions for your permissions where a set of one or more groups (and their hierarchies) is permitted to access an object.
To create a new group-based policy, select *Group* in the dropdown list in the upper right corner of the policy listing.
.Add Group-Based Policy
image:{project_images}/policy/create-group.png[alt="Add Group-Based Policy"]
==== Configuration
* *Name*
+
A human-readable and unique string describing the policy. A best practice is to use names that are closely related to your business and security requirements, so you
can identify them more easily.
+
* *Description*
+
A string containing details about this policy.
+
* *Groups Claim*
+
Specifies the name of the claim in the token holding the group names and/or paths. Usually, authorization requests are processed based on an ID Token or Access Token
previously issued to a client acting on behalf of some user. The token must include a claim from where this policy is going to obtain the groups
the user is a member.
+
* *Groups*
+
Allows you to select the groups that should be enforced by this policy when evaluating permissions. After adding a group, you can extend access to children of the group
by marking the checkbox *Extend to Children*. If left unmarked, access restrictions only applies to the selected group.
+
* *Logic*
+
The <<_policy_logic, Logic>> of this policy to apply after the other conditions have been evaluated.

View file

@ -1,5 +1,5 @@
[[_policy_rbac_required]]
=== Defining a Role as Required
==== Defining a Role as Required
When creating a role-based policy, you can specify a specific role as `Required`. When you do that, the policy will grant access
only if the user requesting access has been granted *all* the *required* roles. Both realm and client roles can be configured as such.

View file

@ -45,5 +45,8 @@ This permission is a <<_permission_create_resource, resource-based permission>>,
You can change the default configuration by removing the default resource, policy, or permission definitions and creating your own.
The default resource is created with an **URI** that maps to any resource or path in your application using a **/*** pattern. Before creating your own resources, permissions and policies, make
sure the default configuration doesn't conflict with your own settings.
[NOTE]
The default configuration defines a resource that maps to all paths in your application. If you are about to write permissions to your own resources, be sure to remove the *Default Resource* or change its ```URI``` field to a more specific path in your application. Otherwise, the policy associated with the default resource (which by default always grants access) will allow {project_name} to grant access to any protected resource.

View file

@ -1,5 +1,5 @@
[[_service_rpt_overview]]
==== Requesting Party Token
=== Requesting Party Token
A requesting party token (RPT) is a https://tools.ietf.org/html/rfc7519[JSON web token (JWT)] digitally signed using https://www.rfc-editor.org/rfc/rfc7515.txt[JSON web signature (JWS)]. The token is built based on the OAuth2 access token previously issued by {project_name} to a specific client acting on behalf of an user
or on its own behalf.

View file

@ -1,5 +1,5 @@
[[_service_protection_token_introspection]]
=== Introspecting a Requesting Party Token
==== Introspecting a Requesting Party Token
Sometimes you might want to introspect a requesting party token (RPT) to check its validity or obtain the permissions within the token to enforce authorization decisions on the resource server side.