diff --git a/server_admin/topics/authentication/clients/assembly-client-oidc.adoc b/server_admin/topics/authentication/clients/assembly-client-oidc.adoc index 49fc4ce6ee..df4f9746fd 100644 --- a/server_admin/topics/authentication/clients/assembly-client-oidc.adoc +++ b/server_admin/topics/authentication/clients/assembly-client-oidc.adoc @@ -15,3 +15,4 @@ include::oidc/con-confidential-client-credentials.adoc[leveloffset=+1] include::oidc/proc-using-a-service-account.adoc[leveloffset=+1] include::oidc/con-audience.adoc[leveloffset=+1] + diff --git a/server_admin/topics/sso-protocols/saml.adoc b/server_admin/topics/sso-protocols/saml.adoc deleted file mode 100644 index 85709108b4..0000000000 --- a/server_admin/topics/sso-protocols/saml.adoc +++ /dev/null @@ -1,78 +0,0 @@ -[[_saml]] - -=== SAML - -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. - -There are really two types of use cases when using SAML. The first is an application that asks the {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 -the realm and contains access information (like user role mappings) that the application can use to determine what resources the user -is allowed to access on the application. - -The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks {project_name} -to obtain an SAML assertion it can use to invoke on other remote services on behalf of the user. - -==== SAML Bindings - -SAML defines a few different ways to exchange XML documents when executing the authentication protocol. The _Redirect_ and _Post_ bindings -cover browser based applications. The _ECP_ binding covers REST invocations. There are other binding types but {project_name} only -supports those three. - -===== Redirect Binding - -The _Redirect_ Binding uses a series of browser redirect URIs to exchange information. This is a rough overview of -how it works. - -. The user visits the application and the application finds the user is not authenticated. It generates an XML authentication - request document and encodes it as a query param in a URI that is used to redirect to the {project_name} server. - Depending on your settings, the application may also digitally sign this XML document and also stuff this signature as a query - param in the redirect URI to {project_name}. This signature is used to validate the client that sent this - request. -. The browser is redirected to {project_name}. The server extracts the XML auth request document and verifies - the digital signature if required. The user then has to enter in their credentials to be authenticated. -. After authentication, the server generates an XML authentication response document. This document contains - a SAML assertion that holds metadata about the user like name, address, email, and any role mappings the user - might have. This document is almost always digitally signed using XML signatures, and may also be encrypted. -. The XML auth response document is then encoded as a query param in a redirect URI that brings the browser back - to the application. The digital signature is also included as a query param. -. The application receives the redirect URI and extracts the XML document and verifies the realm's signature to make - sure it is receiving a valid auth response. The information inside the SAML assertion is then used to make - access decisions or display user data. - -===== POST Binding - -The SAML _POST_ binding works almost the exact same way as the _Redirect_ binding, but instead of GET requests, XML -documents are exchanged by POST requests. The _POST_ Binding uses JavaScript to trick the browser into making a POST request to -the {project_name} server or application when exchanging documents. Basically HTTP responses contain an HTML document -that contains an HTML form with embedded JavaScript. When the page is loaded, the JavaScript automatically invokes the form. -You really don't need to know about this stuff, but it is a pretty clever trick. - -_POST_ binding is usually recommended because of security and size restrictions. When using _REDIRECT_ the SAML response -is part of the URL (it is a query parameter as it was explained before), so it can be captured in logs and it is considered -less secure. Regarding size, if the assertion contains a lot or large attributes sending the document inside the HTTP payload -is always better than in the more limited URL. - -===== ECP - -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. - -===== Artifact Binding - -The SAML _Artifact_ binding works alongside the standard _Redirect_ or _POST_ bindings. The purpose of this binding is -to prevent SAML messages from passing by the browser. When a SAML message would be sent to the application or the {project_name}, it is instead saved and in its place a Redirect or a POST is sent containing an unique identifier (this is the artifact). -The contacted party uses SOAP to send a message containing the artifact directly to the originator, which in turn replies via SOAP with the saved SAML message. - -This binding can have some security benefits, for example when the user is not trusted with the contents of a SAML assertion. Instead, they are exchanged between the application and {project_name} via SOAP. - -==== {project_name} Server SAML URI Endpoints - -{project_name} really only has one endpoint for all SAML requests. - -`http(s)://authserver.host/auth/realms/{realm-name}/protocol/saml` - -All bindings use this endpoint. diff --git a/server_admin/topics/users.adoc b/server_admin/topics/users.adoc deleted file mode 100644 index 6aa32ecab5..0000000000 --- a/server_admin/topics/users.adoc +++ /dev/null @@ -1,16 +0,0 @@ - -== User Management - -This section describes the administration functions for managing users. - -include::users/proc-searching-user.adoc[leveloffset=2] -include::users/proc-creating-user.adoc[leveloffset=2] -include::users/proc-deleting-user.adoc[leveloffset=2] -include::users/proc-configuring-user-attributes.adoc[leveloffset=2] -include::users/credentials.adoc[leveloffset=2] -include::users/con-required-actions.adoc[leveloffset=2] -include::users/impersonation.adoc[leveloffset=2] -include::users/user-registration.adoc[leveloffset=2] -include::users/recaptcha.adoc[leveloffset=2] -include::users/personal_data.adoc[leveloffset=2] - diff --git a/server_admin/topics/users/credentials.adoc b/server_admin/topics/users/credentials.adoc deleted file mode 100644 index a99b86c27a..0000000000 --- a/server_admin/topics/users/credentials.adoc +++ /dev/null @@ -1,60 +0,0 @@ -[[_user-credentials]] -= User Credentials - -When viewing a user if you go to the `Credentials` tab you can manage a user's credentials. - -.Credential Management -image:{project_images}/user-credentials.png[] - -The credentials are listed in a table, which has the following fields: - -Position:: - The arrow buttons in this column allows you to shift the priority of the credential for the user, with the topmost credential having the highest priority. - This priority determines which credential will be shown first to a user in case of a choice during login. The highest priority of those available to the - user will be the one selected. -Type:: - This shows the type of the credential, for example `password` or `otp`. -User Label:: - This is an assignable label to recognise the credential when presented as a selection option during login. It can be set to any value to describe the - credential. -Data:: - This shows the non-confidential technical information about the credential. It is originally hidden, but you can press `Show data...` to reveal it for a - credential. -Actions:: - This column has two buttons. `Save` records the value of the User Label, while `Delete` will remove the credential. - -== Creating a Password for the User - -If a user doesn't have a password, or if the password has been deleted, the `Set Password` section will be shown on the page. - -.Credential Management - Set Password -image:images/user-credentials-set-password.png[] - -To create a password for a user, type in a new one. Click on the `Set Password` button after you've typed everything in. -If the `Temporary` switch is on, this new password can only be used once and the user will be asked to change their password after they have -logged in. - -If a user already has a password, it can be reset in the `Reset Password` section. - -Alternatively, if you have <<_email, email>> set up, you can send an email to the user that asks -them to reset their password. Choose `Update Password` from the `Reset Actions` list box and click `Send Email`. You can optionally -set the validity of the e-mail link which defaults to the one preset in `Tokens` tab in the realm settings. -The sent email contains a link that will bring the user to the update password screen. - -Note that a user can only have a single credential of type password. - -== Creating other credentials - -You cannot configure other types of credentials for a specific user within the Admin Console. This is the responsibility of the user. -You can only delete credentials for a user on the `Credentials` tab, for example if the user has lost an OTP device, or if a credential -has been compromised. - -== Creating an OTP - -If OTP is conditional in your realm, the user will have to go to the User Account Management service to re-configure a new OTP generator. If OTP is required, then the user will be asked -to re-configure a new OTP generator when they log in. - -Like passwords, you can alternatively send an email to the user that will ask them to reset their OTP generator. Choose -`Configure OTP` in the `Reset Actions` list box and click the `Send Email` button. The sent email -contains a link that will bring the user to the OTP setup screen. You can use this method even if the user already has an OTP credential, -and would like to set up some more. diff --git a/server_admin/topics/users/ref-user-credentials.adoc b/server_admin/topics/users/ref-user-credentials.adoc index 5b6a36e6c4..eaa7abf894 100644 --- a/server_admin/topics/users/ref-user-credentials.adoc +++ b/server_admin/topics/users/ref-user-credentials.adoc @@ -32,4 +32,4 @@ Actions:: You cannot configure other types of credentials for a specific user in the admin console; that task is the user's responsibility. -You can delete the credentials of a user in the event a user loses an OTP device or if credentials have been compromised. You can only delete credentials of a user in the *Credentials* tab. \ No newline at end of file +You can delete the credentials of a user in the event a user loses an OTP device or if credentials have been compromised. You can only delete credentials of a user in the *Credentials* tab.