update documentation to 3.0; put maven central repo as the first one to

check

Author: golbi

documentation/src/main/doc/authentication.txt

@@ -63,7 +63,7 @@ authenticator works as follows:
 an information about the logged user.
 2. If the remote login was successful the remotely provided data is mapped to the local representation
 (translated, enhanced, filtered...) using an _input translation profile_ which is assigned to the 
-authenticator. Input translation profiles are discussed in <<translation>>. In effect of translation: 
+authenticator. Input translation profiles are discussed in <<input-translation>>. In effect of translation: 
 	* The remote user may be mapped to an existing account (at not-the-first login
 	or when it is possible to automatically map remote user to local account using some attribute as email). 
 	In such case authentication is finished just after the translation.
@@ -84,6 +84,10 @@ for the first time.
 Account association is enabled by default. It requires additional login to the existing account in a 
 popup window. It can be turned off in authenticator settings.
 
+
+include::input-translation.txt[]
+
+
 === Step-up and repeated authentication
 
 For certain sensitive operations Unity may be configured (and by default is) to require additional or step-up
@@ -125,3 +129,4 @@ to 600s then user won't need to perform additional authentication for one minute
 if there is no applicable additional authentication authenticator for the user (what typically means that system
 is misconfigured).    
 
+

documentation/src/main/doc/branding.txt

@@ -181,11 +181,14 @@ screen. See the main server reference documentation: <<configuration>>.
 
 Unity offers internationalization (i18) features out of the box. However, the list of available languages
 is hardcoded and currently includes only English (en), Polish (pl) and German (de) locales. English locale is
-the default one and all default messages are in this language. The Polish and German translations are mostly complete with the
-exception of the Admin UI. Administrator can configure which of the supported locale are enabled (see +unityServer.conf+ documentation).
+the default one and all default messages are in this language. Couple of other translations are mostly complete with the
+exception of the Admin Console which is English only. 
+Administrator can configure which of the supported languages are enabled 
+(see +unityServer.conf+ documentation for up to date list of allowed ones in <<configuration>>).
 
 If you would like to have other locale supported please contact us via the mailing list - there is no problem to add 
-them or to allow for admin-configured locales outside from those predefined in distribution.
+them or to allow for admin-configured locales outside from those predefined in distribution. We also use Weblate at 
+https://hosted.weblate.org/projects/unity-idm for collecting open source improvements to existing translations.
 
 Actual translations are fully controlled by Unity administrator. 
 In the +i18n/+ subfolder of the configuration directory a copy of all system messages is stored. 

documentation/src/main/doc/config/notifications.txt

@@ -33,7 +33,7 @@ ${VARIABLE_NAME}
 
 Besides variables, message template may also include other templates which are set as "generic" fragments.
 
-Message templates are configured using Admin UI (Server management->Message templates). 
+Message templates are configured using Admin Console (Setting->Message templates). 
 It is also possible to configure them with configuration file (by default +msgTemplates.properties+). 
 
 Variables are replaced dynamically with concrete values when a message is prepared to be sent. Naturally

documentation/src/main/doc/config/storage.txt

@@ -14,7 +14,7 @@ The following option allows to select the database backend:
 unityServer.storage.engine=rdbms  # 'hz' is another possible option 
 ----
 
-Note that the Admin UI provides a possibility to create a dump JSON dump of the complete server state and to restore 
+Note that the Admin Console provides a possibility to create a dump JSON dump of the complete server state and to restore 
 the system from such dump regardless of the selected storage engine.
 
 

documentation/src/main/doc/contents-management.txt

@@ -140,7 +140,7 @@ attribute: +sys:AuthorizationRole+. The attribute is of enumeration type, and th
 
 By assigning this attribute to entities, those entities are granted some roles and therefore are authorized to perform 
 certain operations in Unity. The detailed information on what is allowed for each role holder is provided 
-in attribute type description (see Schema Management->Attribute Types). The two most important roles are:
+in attribute type description (see Directory setup->Attribute types). The two most important roles are:
 
  . +System manager+ who is authorized to perform all actions and
  . +Regular user+ who can perform all the typical operations reserved for users, i.e. read information about itself.
@@ -193,28 +193,17 @@ To enable confirmations the following basic elements needs to be configured:
 . There must be a message template (or templates) suitable for use with confirmation facility. See <<notifications>>.
 . To confirm attributes at least one attribute type must be defined which will use the +verifiableEmail+ syntax. 
 What's more each such attribute type must have confirmations enabled and configured by selecting a proper 
-message template (see below).
+message template in its definition.
 . To confirm email identities, identity confirmations must be enabled and configured by selecting a proper 
-message template (see below).
-
-The configuration of confirmations (for identities and for each email attribute type) is performed in the 
-Server management -> Confirmations configuration tab of the Admin UI. It is rather simplistic as the only 
-really variable property is the template to be used.
-
-Note that Unity contains a convenient initializer script which can be enabled in the +unityServer.conf+ to load 
-default confirmation configurations on startup:
-
-----
-unityServer.core.script.1.file=scripts/confirmationsInitializer.groovy
-unityServer.core.script.1.trigger=pre-init
-----
+message template in its definition.
 
 Later in this section we assume that the confirmations were set up as described above.
 
 ==== When confirmations are sent?
 
 Whenever an email attribute or identity is created or changed manually in Unity interface 
-the confirmation message is sent. The sole exception is a change of an attribute by administrator via the Admin UI: 
+it is assumed to be not confirmed and the confirmation message is sent. 
+The exception is a change of an attribute by administrator via the Admin Console: 
 it is possible to control whether the attribute value should be added as confirmed or not.
 
 Confirmations are also sent whenever a registration request is submitted, with an e-mail attribute or identity which
@@ -231,7 +220,7 @@ Unity also takes care not to resent a confirmation if the same e-mail address wa
 identity and attribute (or multiple attributes). Then only a single confirmation is sent and is used to 
 confirm all elements. 
 
-It is also possible to reset a confirmation state by the administrator (from Admin UI) 
+It is also possible to reset a confirmation state by the administrator (from Admin Console) 
 by setting the unconfirmed state of an attribute value.  
 
 ==== Registration forms and confirmations

documentation/src/main/doc/endpoint-admin.txt

@@ -1,18 +1,9 @@
-=== Web Admin UI endpoint
+=== Web Admin UI endpoint (deprecated)
 
 Endpoint type:: +WebAdminUI+
 Binding:: Web
 Exposed paths:: +/admin+
 Default path:: +/admin+
 
-Web Admin UI is the first place to visit after server installation and startup as it offers
-a administrator oriented management interface. 
-By default it is accessible under the link: +pass:[https://localhost:2443/ENDPOINT-CONFIGURED-CONTEXT/admin]+  
-or simply +pass:[https://localhost:2443/ENDPOINT-CONFIGURED-CONTEXT]+ as the +/admin+ path is the default.
-
-The features of the Web Admin interface are covered in the <<contents-management>> section.
-
-Currently the Admin UI endpoint offers the same options as the Home endpoint naturally including the options common 
-for all web endpoints. The Home endpoint's options 
-can usually be left unchanged as are used only to control the logged user's profile screen, which is also available 
-for administrator's convenience in the Admin UI.
+Web Admin UI is a legacy administrative interface, a predecessor of Admin Console. This endpoint is going to be dropped in one 
+subsequent releases, so switching to Admin Console is highly suggested. Admin Console offers a better and more capable UI. 

documentation/src/main/doc/endpoint-console.txt

@@ -0,0 +1,15 @@
+=== Web Admin Console endpoint
+
+Endpoint type:: +WebConsoleUI+
+Binding:: Web
+Exposed paths:: +/console+
+Default path:: +/console+
+
+Web Admin Console is the first place to visit after server installation and startup as it offers
+an administrator oriented management interface. 
+By default it is accessible under the link: +pass:[https://localhost:2443/ENDPOINT-CONFIGURED-CONTEXT/console]+  
+or simply +pass:[https://localhost:2443/ENDPOINT-CONFIGURED-CONTEXT]+ as the +/console+ path is the default.
+
+The features of the Console interface are covered in the <<contents-management>> section.
+
+Currently the Admin Console endpoint offers only options common for all web endpoints.

documentation/src/main/doc/endpoint-upman.txt

@@ -42,7 +42,7 @@ other actions taken for those users as configured in the forms. However, project
 re-configure any of the project forms, therefore in a sense a person controlling the forms, also have some 
 general responsibility and control over the project.
 
-As it can be guessed from the above description that all UpMan triggered changes are visible in Admin UI, 
+As it can be guessed from the above description that all UpMan triggered changes are visible in Admin Console, 
 including project subgroups, project members, registration requests etc. 
 
 ==== Using UpMan

documentation/src/main/doc/endpoints.txt

@@ -185,8 +185,10 @@ the authentication and what data will be shared with the requesting service. Det
 IdP endpoints, e.g. OAuth endpoint shows requested scopes, while SAML endpoint doesn't. Users can save the consent 
 decision and then consent is skipped for them. It is also possible to turn off the consent screen completely.   
 
+include::output-translation.txt[]
 
-include::endpoint-admin.txt[]
+
+include::endpoint-console.txt[]
 
 include::endpoint-home.txt[]
 
@@ -203,6 +205,6 @@ include::endpoint-restadmin.txt[]
 include::endpoint-wellknown.txt[]
 
 
-
+include::endpoint-admin.txt[]
 
 

…cumentation/src/main/doc/translation.txt …ation/src/main/doc/input-translation.txtdocumentation/src/main/doc/translation.txt renamed to documentation/src/main/doc/input-translation.txt documentation/src/main/doc/translation.txt renamed to documentation/src/main/doc/input-translation.txt

@@ -1,22 +1,15 @@
-[[translation]]
-== Translation profiles configuration
+[[input-translation]]
+=== Input translation
 
 Translation profile is a named, ordered list of conditional rules. The rules are used to 
-modify the information about a principal being processed by Unity. Such situation occurs when:
-
-. Remote user was externally authenticated and its data is consumed by Unity. In this case
-translation is performed by so called _input translation profiles_.
-. Information about Unity's entity is being exposed to outside world with an IdP-like endpoint
-as SAML web endpoint.  In this case translation is performed by so called _output translation profiles_.
+modify the information about a principal being processed by Unity. Input translation profile is used when 
+a remote user was externally authenticated and its data is consumed by Unity.
 
 For instance, an input translation profile can change remote attribute 'size' name to
 'width' and insert a remotely authenticated user to the local database (to a desired group)
-if the user is not yet there. An output profile can return an additional dynamic identity named 'email' 
-with a value of an email attribute.   
+if the user is not yet there.
 
-The following subsections cover both types of translation profiles in details. Though many of the features
-are common. The profiles are managed with the Admin UI in the Server management->Translation profiles tab.
-The profile has a name and a list of rules. Each rule has a condition and an action.
+A profile consists of a list of rules. Each rule has a condition and an action.
 
 Conditions are used to dynamically turn action execution on or off. Conditions (as well as some of the arguments 
 of translation actions have) have to be specified as _MVEL expressions_. Such expressions allow for a powerful, 
@@ -35,14 +28,8 @@ the most popular condition is simply: +true+.
 Actions are different for each type of the profile. The editor provides you with helpful interface to create them.
 
 
-
-[[input-translation]]
-=== Input translation
-
 An input translation profile is always associated with a _remote authenticator in its configuration_.
-It is a mandatory setting, all remote authenticators must have one profile associated. This is because it is
-typically not possible to provide a sensible default mapping of remote data to the configurable schema used in 
-Unity.  
+It is a mandatory setting, all remote authenticators must have one profile associated.
 
 Input translation profile (both conditions and rules) operate on a data structure which is initially
 filled by the protocol specific component. The structure can contain:
@@ -87,26 +74,17 @@ to remove all stale data: attributes, group memberships, identities. The data is
 was previously created by the same profile, basing on input from the same remote IdP 
 and which was not reproduced during the current invocation of the profile.
 
-==== Translation profile creation wizard and dry-run
-
-Unity provides two sophisticated features helping in input translation profile management. First of all it is possible
-to use a translation profile creation *wizard*.
+==== Translation profile testing
 
-The wizard can be activated from the Server management->Translation profiles view. Currently the wizard can be used
-to create a profile basing on an available remote authenticator, so you need to configure it first in a regular way.
-However any (even empty) translation profile can be initially set for this authenticator.   
-
-After launching the wizard a popup window appears allowing you to select any of the remote authenticators available
-in the system (regardless of their assignment to endpoints). The authentication is performed in a sandbox environment
-so it is not influencing the running system. After finishing the remote authentication the popup window disappears
-and a visual translation profile editor is displayed. The whole information received from the remote IdP is shown,
-and can be dragged into expressions of the profile being created. After the profile is configured it must be saved
-and can be assigned to the authenticator.
-
-Besides the wizard it is also possible to perform a detailed testing of an already existing translation profile. 
-This *dry run* feature is available from the same menu as the wizard and begins in the same way: with a sandboxed 
-authentication. However, the last step is different: instead of an editor a detailed information on the profile's 
-application to the data provided by remote IdP is presented, including even the relevant server's log.   
+Unity provides a sophisticated feature helping to work with input translation profile.
+ 
+Testing can be performed on an existing remote authenticator with some profile configured. 
+This feature is available from the Authentication -> Facilities main view (Test button). 
+Test begins with a sandboxed authentication in a popup window, where one can select any of the remote 
+authentication options available in the system. 
+After authentication (failed or successful) a detailed information on the profile's 
+application to the data provided by remote IdP (and naturally the data itself) is presented, 
+including even a relevant server's internal log.   
 
 
 ==== Reference
@@ -209,71 +187,3 @@ Finally the value of the identity provided by remote IdP is available as follows
 id
 ----
 
-
-
-
-
-
-=== Output translation
-
-An output translation profile can be associated with an IdP-like endpoint as the SAML endpoints.
-It can be used to filter the data being exposed (so called attribute release policies can be implemented
-with output profiles). Also it can dynamically create additional data to be returned. It is even possible to
-store the dynamically created data back into the local Unity database, so it becomes a regular data.
-
-Configuration of output profiles is optional. If no profile is manually installed on an endpoint, then a so called
-_default output profile_ is used. The default profile is simplistic: it doesn't filter anything and anly adds 
-one additional attribute: +memberOf+ with all groups of the principal as value. 
-
-Output translation profile operate on a data structure which is initially
-filled by Unity with all attributes and identities of the queried principal. Attributes are from the group configured
-in the endpoint.
-
-MVEL context used in conditions and as value of some action parameters can use the following variables:
-
-. +protocol+ Name of the protocol being used 
-. +protocolSubtype+ Name of the protocol variant
-. +requester+ Name of the requester
-. +usedGroup+ Unity group from which attributes are served 
-. +subGroups+ All sub groups of the Unity group from which attributes are served
-. +attr+ Map indexed with principal's attribute names. Value of each entry is a single value of the attribute. 
-If the attribute is multi-valued then the first value is returned. 
-If the attribute has no value then empty string is returned. 
-. +attrs+ Map indexed with attribute names. Value of each entry is a list of the attribute values.
-. +attrObj+ Map indexed with attribute names. Value of each entry is a list of all values provided as 
-objects with attribute-type specific contents. Useful for inspecting complex types like email and accessing its confirmation status.
-. +requesterAttr+, +requesterAttrs+ and +requesterObj+ attributes of the requester, 
-if it is represented by an entity in Unity. This is the case for OAuth authentication.
-. +idsByType+ Map of identity values indexed by type.
-. +groups+ List of all groups the user is a member. 
-. +authenticatedWith+ List of identities that were used to authenticate the user. 
-If remote authentication was used the list contains a single identity that was used 
-to map the remote user to the local entity (as chosen by the input translation profile). 
-The list can have two elements when MFA was used.
-. +importStatus+ Map indexed with importer names which are enabled for the endpoint on which output profile 
-is executed. Status of each importer is value of map entries. The following values are possible: +notApplicable+ and
-+success+.
-. +idp+ Identifier of a remote IdP that was used to authenticate the current user's session. 
-In case when only a local authentication was used, the value is set to +_LOCAL+.  
- 
-
-Example output profile:
-------
-1: Condition: idsByType contains 'userName'
-Action: createAttribute
-Action parameters:
-  attributeName = userid
-  expression = idsByType['userName']
-
-2: Condition: true
-Action: filterAttribute
-Action parameters:
-  unityAttribute = email
-------
-
-The above profile in the first action creates a new attribute +userid+ with a value of user's identity 
-of the +userName+ type. The attribute is added only if the principal has such identity.
-The second rule hides the email attribute unconditionally.
-
-Additional examples of expressions and conditions can be found in the <<input-translation>> above. Note however
-that only the variables from the output MVEL context can be used.