From 997de367af5eb6115602cb6f639b80de423a9b7d Mon Sep 17 00:00:00 2001 From: Bill Burke Date: Fri, 3 Jun 2016 10:13:57 -0400 Subject: [PATCH] fixes --- topics/authentication/kerberos.adoc | 3 +-- topics/clients.adoc | 1 + topics/overview/concepts.adoc | 2 +- topics/sso-protocols/oidc.adoc | 4 +--- topics/sso-protocols/saml.adoc | 7 +++---- 5 files changed, 7 insertions(+), 10 deletions(-) diff --git a/topics/authentication/kerberos.adoc b/topics/authentication/kerberos.adoc index 23ba178b52..f1696bd457 100755 --- a/topics/authentication/kerberos.adoc +++ b/topics/authentication/kerberos.adoc @@ -95,7 +95,7 @@ to _required_ then all users must have Kerberos enabled for their browser. ===== Configure Kerberos User Storage Federation Provider Now that the SPNEGO protocol is turned on at the authentication server, you'll need to configure how {{book.project.name}} interprets the Kerberos ticket. -This is done through >. We have 2 different federation providers with Kerberos authentication support. +This is done through <>. We have 2 different federation providers with Kerberos authentication support. If you want to authenticate with Kerberos backed by an LDAP server, you have to first configure the <>. If you look at the configuration page for your LDAP provider you'll see a `Kerberos Integration` section. @@ -168,7 +168,6 @@ GSSContext context = gssManager.createContext(serviceName, krb5Oid, ---- Note that you also need to configure `forwardable` kerberos tickets in `krb5.conf` file and add support for delegated credentials to your browser. -For details, see the kerberos example from {{book.project.name}} examples set as mentioned above. WARNING: Credential delegation has some security implications so only use it if you really need it. It's highly recommended to use it together with HTTPS. diff --git a/topics/clients.adoc b/topics/clients.adoc index 201b3d4b7e..10cbc81feb 100644 --- a/topics/clients.adoc +++ b/topics/clients.adoc @@ -1,3 +1,4 @@ +[[_clients]] == Managing Clients diff --git a/topics/overview/concepts.adoc b/topics/overview/concepts.adoc index d3026c92c4..ccbb291683 100755 --- a/topics/overview/concepts.adoc +++ b/topics/overview/concepts.adoc @@ -17,7 +17,7 @@ credentials:: roles:: Roles identify a type or category of user. `Admin`, `user`, `manager`, and `employee` are all typical roles that may exist in an organization. Applications often assign access and permissions to specific roles rather than individual users as dealing - with users can be too fine grained and hard to manage + with users can be too fine grained and hard to manage. user role mapping:: A user role mapping defines a mapping between a role and a user. A user can be associated with zero or more roles. This role mapping information can be encapsulated into tokens and assertions so that applications can decide access permissions on diff --git a/topics/sso-protocols/oidc.adoc b/topics/sso-protocols/oidc.adoc index 75e0848f75..3860578690 100644 --- a/topics/sso-protocols/oidc.adoc +++ b/topics/sso-protocols/oidc.adoc @@ -55,9 +55,7 @@ to provide a client secret when they exchange the temporary codes for tokens. _ _Public_ clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the client. HTML5/JavaScript clients actually always have to be _public_ clients because there is no way to transmit the client secret to them in a secure manner. Again, this is ok so long as you use HTTPS and strictly enforce redirect URI registration. This guide goes more detail -into this in the - -// DOCS REMARK: Please update the cross-reference as it does not resolve correctly. <> chapter. +into this in the <> chapter. ===== Implicit Flow diff --git a/topics/sso-protocols/saml.adoc b/topics/sso-protocols/saml.adoc index 8a5b4aa009..15b415014b 100644 --- a/topics/sso-protocols/saml.adoc +++ b/topics/sso-protocols/saml.adoc @@ -2,13 +2,11 @@ === SAML -link://https://saml.org/fill/this/in[SAML 2.0] is a similar specification to OIDC but a lot older and more mature. It has its roots in SOAP and the plethora +link:http://saml.xml.org/saml-specifications[SAML 2.0] is a similar specification to OIDC but a lot older and more mature. It has its roots in SOAP and the plethora of WS-* specifications so it tends to be a bit more verbose than OIDC. SAML 2.0 is primarily an authentication protocol that works by exchanging XML documents between the authentication server and the application. XML signatures and encryption is used to verify requests and responses. -In {{book.project.name}} SAML serves two types of use cases: browser applications and REST invocations. - There is really two types of use cases when using SAML. The first is an application that asks the {{book.project.name}} server to authenticate a user for them. After a successful login, the application will receive an XML document that contains something called a SAML assertion that specify various attributes about the user. This XML document is digitally signed by @@ -55,7 +53,8 @@ You really don't need to know about this stuff, but it is a pretty clever trick. ===== ECP -TODO. Ask Pedro to fill in. +ECP stands for "Enhanced Client or Proxy", a SAML v.2.0 profile which allows for the exchange of SAML attributes outside the context of a web browser. +This is used most often for REST or SOAP-based clients. ==== {{book.project.name}} Server OIDC URI Endpoints