Resolving conflicts
This commit is contained in:
AndyMunro
Marek Posolda
parent
2cb26dd703
commit
2e8827cf1a
5 changed files with 2 additions and 155 deletions
|
|
@ -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/proc-using-a-service-account.adoc[leveloffset=+1]
|
||||||
|
|
||||||
include::oidc/con-audience.adoc[leveloffset=+1]
|
include::oidc/con-audience.adoc[leveloffset=+1]
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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]
|
|
||||||
|
|
||||||
|
|
@ -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.
|
|
||||||
Loading…
Reference in a new issue