summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorInstrumental <jonathan.gathman@att.com>2019-03-18 10:18:55 -0500
committerInstrumental <jonathan.gathman@att.com>2019-03-18 10:18:58 -0500
commit68a514e92ea55e70241dc93cc5e9e46d3fc1b6c7 (patch)
tree9c19f61b9894e595dd44a5fec1fc5b82bfa53e6a
parent57effd69fb15e0c73f85296d10ff6b358a6cbebb (diff)
Document TrustPrincipal
Issue-ID: AAF-791 Change-Id: I39aac17851a93f810cf9aeac602d15592da65dc1 Signed-off-by: Instrumental <jonathan.gathman@att.com>
-rw-r--r--docs/sections/configuration/trust.rst59
1 files changed, 59 insertions, 0 deletions
diff --git a/docs/sections/configuration/trust.rst b/docs/sections/configuration/trust.rst
new file mode 100644
index 00000000..215e4e73
--- /dev/null
+++ b/docs/sections/configuration/trust.rst
@@ -0,0 +1,59 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
+
+Trusting Other Authentication Entities
+==========================================
+
+Few Transactions in an Organization of any size touch only one service. This is even more true with MicroService Architecture.
+
+In AAF, EVERY Tranasction must be Authenticated from the Caller, but in App-to-App situations, not every Authorization should be
+evaluated on the underlying caller.
+
+SERVICE Configuration
+----------------------
+ 1) Define the Permission this App will use for Trust, and add to Service's "Cadi Properties"
+ Ex:
+
+ cadi_trust_perm=org.onap.aai.user_chain|com.att|trust
+
+ 2) In the AAF Service, user the AAF CMDline interface to create Permission that matches above, and role
+
+ Given that an App may trust "ONAP Portal" to have validated an end-user, and that ONAP Portal's Identity is portal@portal.onap.org,
+
+ role create org.onap.aai.trusted portal@portal.onap.org
+ perm create org.onap.aai.user_chain|org.onap|trust org.onap.aai.trusted
+
+ Note: These instructions are for first Identity, which both creates Role and Perm, and adds User, Grants Perm. Admin may separate the commands of "create" and "grant"/"add", see CUI help.
+
+CLIENT Transaction
+-------------------
+ The CADI client, when used, will create USER_CHAIN property automatically, but not all CLIENTs are CADI. For NON-CADI HTTP Clients, do the following:
+
+ * Create an HTTP Header property called “USER_CHAIN”
+ * The syntax for the value is:
+
+ <AAF ID>:<service Reference>:<Authentication Type>[:AS][,<ID>:<reference>:<type>]*
+
+ Where “:AS” is the indicator that you want the Service to treat the transaction as if it came from the end client.
+ <AAF_ID> is the Identity of the Calling Client (End Client)
+ <service Reference> should be the Service's AAF Namespace and microservice name, separated by '.'
+ <Authentication Type> should be how the Client was Authenticated
+
+ BAth - BasicAuth
+ x509 - X509 Client Certificate
+
+ <other Organization defined Types are acceptable, but should be 4 chars long for ease of use, and match any TAF Adapters used to validate>
+
+ Example:
+ USER_CHAIN: demo@people.osaaf.org:org.onap.aai:BAth:AS
+
+ What Happens:
+ Cadi Code (such as what is in CadiFilter)
+ * Reads the USER_CHAIN
+ * IF the last USER_CHAIN Entry ends with ":AS"...
+ * Checks to see if the Identity is the same as Service (nice for Model-View-Controller and multi-MS applications) OR
+ * if the incoming caller has the Permission specified in "cadi_trust_perm"
+
+ * THEN a new "TrustPrincipal" is created, which takes on the identity of the ":AS" identified Identity for the purposes of Authentication.
+