9:57 a.m.
Author: aakanksha_writer
Date: 2013-03-03 10:57:47 -0500 (Sun, 03 Mar 2013)
New Revision: 9192
Modified:
epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AccessingUserProfile.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2.xml
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2_Salesforce_and_Google_Integration.xml
Log:
BZ#911516,856448,856430 updated
Modified: epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml
===================================================================
--- epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-03-01 06:46:33
UTC (rev 9191)
+++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-03-03 15:57:47
UTC (rev 9192)
@@ -7,6 +7,20 @@
<title>Revision History</title>
<simpara>
<revhistory>
+ <revision>
+ <revnumber>6.0.0-54</revnumber>
+ <date>Mon Mar 4 2013</date>
+ <author>
+ <firstname>Aakanksha</firstname>
+ <surname>Singh</surname>
+ <email/>
+ </author>
+ <revdescription>
+ <simplelist>
+ <member>BZ#911516,856448,856430 - Incorporated new QE Review
comments.</member>
+ </simplelist>
+ </revdescription>
+ </revision>
<revision>
<revnumber>6.0.0-53</revnumber>
<date>Wed Feb 27 2013</date>
Modified:
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AccessingUserProfile.xml
===================================================================
---
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AccessingUserProfile.xml 2013-03-01
06:46:33 UTC (rev 9191)
+++
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AccessingUserProfile.xml 2013-03-03
15:57:47 UTC (rev 9192)
@@ -22,6 +22,6 @@
</listitem>
</orderedlist>
<para>
- Both alternatives are probably better then {{OrganizationService orgService =
getApplicationComponent(OrganizationService.class)}} because you can use them from your
own portlets or servlet/portlet filters. The variant with {{getApplicationComponent}}
works only from WebUI.
+ Both alternatives are probably better than <code>OrganizationService
orgService = getApplicationComponent(OrganizationService.class)</code> because you
can use them from your own portlets or servlet/portlet filters. The variant with
<literal>getApplicationComponent</literal> works only from WebUI.
</para>
</chapter>
Modified:
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml
===================================================================
---
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2013-03-01
06:46:33 UTC (rev 9191)
+++
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/AuthenticationAuthorizationOverview.xml 2013-03-03
15:57:47 UTC (rev 9192)
@@ -49,9 +49,10 @@
<para>
Authentication workflow consists of HTTP requests and redirects which include
handshakes. Currently only Servlet 3.0 containers are supported, so authentication is
triggered programmatically from Servlet API.
</para>
- <para>In
<filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename>,
authentication is triggered by accessing a secured URL
<systemitem>_/dologin_</systemitem>:
+ <para>In
<filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/portal.war/WEB-INF/web.xml</filename>,
authentication is triggered by accessing a secured URL <systemitem>
/dologin</systemitem>:
</para>
- <programlisting language="XML"><security-constraint>
+ <programlisting language="XML">
+<security-constraint>
<web-resource-collection>
<web-resource-name>user
authentication</web-resource-name>
<url-pattern>/dologin</url-pattern>
@@ -70,7 +71,7 @@
This means that access to URLs (such as <ulink
url="http://localhost:8080/portal/dologin"
type="http">http://localhost:8080/portal/dologin</ulink>) will directly
trigger J2EE authentication in the case that the user is not already logged in.
</para>
<para>
- Access to this URL also means that the user needs to be in the JAAS group
<emphasis>users</emphasis>, otherwise they can authenticate but will receive
an HTTP error: <emphasis>403 Forbidden</emphasis>, for example.
+ Access to this URL means that the user needs to be in the JAAS group
<emphasis>users</emphasis>, otherwise they can authenticate but will receive
an HTTP error: <emphasis>403 Forbidden</emphasis>.
</para>
<para>
In the next part of the file we can see that authentication is FORM based and
it starts by redirection to <emphasis>/login</emphasis> URL, which is mapped
to <literal>LoginServlet</literal>.
@@ -101,7 +102,7 @@
Changes to the appearance of this login page can be made in this JSP file.
Alternatively you can create an extension and override this page via extension if you
don't want to edit it directly. You can also change images or CSS placed in
<filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/login/skin</filename>.
</para>
<para>
- After a user submits the login form, they are redirected to the login URL:
<ulink
url="http://localhost:8080/portal/login?username=root&password=gtn&initialURI=/portal/classic"
type="http">http://localhost:8080/portal/login?username=root&password=gtn&initialURI=/portal/private/classic</ulink>.
+ After a user submits the login form, the LoginServlet will store credentials
and trigger WCI login, which delegates to Servlet API (method
HttpServletRequest.login(String username, String password) available in Servlet 3.0) and
additionally triggers WCI Authentication listeners. Login through Servlet API delegates to
JAAS.
</para>
<para>
This URL is mapped to <literal>LoginServlet</literal> servlet,
which stores credentials and redirects again to
<literal>LoginServlet</literal>. LoginServlet triggers WCI login, which
delegates to Servlet API (method HttpServletRequest.login(String username, String
password) available in Servlet 3.0) and additionally triggers WCI Authentication
listeners. Login through Servlet API delegates to JAAS.
@@ -125,7 +126,7 @@
<module-option name="realmName" value="gatein-domain" />
<module-option name="password-stacking" value="useFirstPass"
/>
</login-module>
- <login-module
code="org.exoplatform.services.security.j2ee.JBossEAP6LoginModule"
flag="required">
+ <login-module
code="org.exoplatform.services.security.j2ee.JBossAS7LoginModule"
flag="required">
<module-option name="portalContainerName"
value="portal"/>
<module-option name="realmName" value="gatein-domain"/>
</login-module>
@@ -149,22 +150,22 @@
<term>SSODelegateLoginModule</term>
<listitem>
<para>
- It is useful only if SSO authentication is enabled (disabled by default.
It can be enabled through properties in configuration.properties file and in this case it
delegates the work to another real login module for SSO integration. If SSO is disabled,
SSODelegateLoginModule is simply ignored. See <xref
linkend="sect-SSO_Single_Sign_On_-Central_Authentication_Service"/>
properties details for more details. If SSO is used and SSO authentication succeed, the
special Identity object will be created and saved into shared state map (Map, which is
shared between all login modules), so that this Identity object can be used by JBoss
Enterprise Application Platform 6 LoginModule or other login modules in the JAAS chain.
+ It is useful only if SSO authentication is enabled (disabled by default).
SSO authentication can be enabled through properties in
<filename>configuration.properties</filename> file and it delegates the work
to another real login module for SSO integration. If SSO is disabled,
<filename>SSODelegateLoginModule</filename> is simply ignored. See <xref
linkend="sect-SSO_Single_Sign_On_-Central_Authentication_Service"/>
properties for more details. If SSO is used and SSO authentication succeeds, the special
Identity object is created and saved into shared state map (Map, which is shared between
all login modules), so that this Identity object can be used by JBossAS7LoginModule or
other login modules in the JAAS chain.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term>JBoss Enterprise Application Platform 6 LoginModule</term>
+ <term>JBossAS7LoginModule</term>
<listitem>
<para>
- Most important login module, which is normally used to perform whole
authentication by itself. First it checks if Identity object has been already created and
saved into sharedState map by previous login modules (like SSODelegateLoginModule,
CustomMembershipLoginModule or SharedStateLoginModule). If not, it triggers real
authentication of user with usage of Authenticator interface and it will use
Authentication.validateUser(Credential[] credentials) which performs real authentication
of username and password against OrganizationService and portal identity database. See
<xref
linkend="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor"/>
for details about Authenticator and about Identity objects. </para>
- <para>In the JBoss Enterprise Application Platform 6 LoginModule.commit
method, the Identity object is registered to IdentityRegistry, which will be used later
for authorization. Also some JAAS principals (UserPrincipal and RolesPrincipal) and
assigned to our authenticated Subject. This is needed for JBoss Enterprise Application
server, so that it can properly recognize the name of the logged user and its roles on an
JBoss Enterprise Application level.
+ Most important login module, which is normally used to perform the whole
authentication by itself. First it checks if Identity object has been already created and
saved into sharedState map by previous login modules (like SSODelegateLoginModule,
CustomMembershipLoginModule or SharedStateLoginModule). If not, it triggers real
authentication of user with usage of Authenticator interface and it will use
<filename>Authentication.validateUser(Credential[] credentials)</filename>
which performs real authentication of username and password against OrganizationService
and portal identity database. See <xref
linkend="sect-Authentication_Authorization_Intro-authenticatorAndRolesExtractor"/>
for details about Authenticator and about Identity objects. </para>
+ <para>In the
<filename>JBossAS7LoginModule.commit</filename> method, the Identity object is
registered to IdentityRegistry, which will be used later for authorization. Also some JAAS
principals (UserPrincipal and RolesPrincipal) are assigned to our authenticated Subject.
This is needed for JBoss Enterprise Application server, so that it can properly recognize
the name of the logged user and its roles on an application server level.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
- Some other login modules are not active by default, but can be added them if you
find them useful.
+ Some other login modules are not active by default, but can be added if needed.
</para>
<variablelist>
<varlistentry>
@@ -174,7 +175,7 @@
Special login module, which can be used to add a user to existing groups
during a successful login of this user. The group name is configurable and by default is
/platform/users group. This login module is not used because in normal environment, users
are already in the /platform/users group. It is useful only for some special setups like
read-only LDAP, where groups of an LDAP user are taken from the LDAP tree so that users
may not be in the /platform/users group, which is needed for successful authorization.
</para>
<para>
- Note that the CustomMembershipLoginModule can't be the first
login module in the LoginModule chain because it assumes that the Identity object is
already available in shared state. So there are two possible cases. For an non-SSO case,
you may need to chain this LM with other login modules, which can be used to establish
Identity and add it into shared state. Those LM can be InitSharedStateLoginModule and
SharedStateLoginModule. For an SSO case, you can add CustomMembershipLoginModule between
SSODelegateLoginModule and JBoss Enterprise Application Platform 6 LoginModule.
+ Note that the CustomMembershipLoginModule can't be the first
login module in the LoginModule chain because it assumes that the Identity object is
already available in shared state. So there are two possible cases. For a non-SSO case,
you may need to chain this login module with other login modules, which can be used to
establish Identity and add it into shared state. Those login modules can be
<filename>InitSharedStateLoginModule</filename> and
<filename>SharedStateLoginModule</filename>. For an SSO case, you can add
<filename>CustomMembershipLoginModule</filename> between
<filename>SSODelegateLoginModule</filename> and JBossAS7LoginModule.
</para>
</listitem>
</varlistentry>
@@ -190,7 +191,7 @@
<term>SharedStateLoginModule</term>
<listitem>
<para>
- It reads username and password from sharedState map from attributes
javax.security.auth.login.name and javax.security.auth.login.password. Then it calls
Authenticator.validateUser(Credential[] credentials), to perform authentication of
username and password against OrganizationService and portal identity database. Result of
successful authentication is object Identity, which is saved to sharedState map.
+ It reads username and password from sharedState map from attributes
<literal>javax.security.auth.login.name</literal> and
<literal>javax.security.auth.login.password</literal>. Then it calls
Authenticator.validateUser(Credential[] credentials), to perform authentication of
username and password against OrganizationService and portal identity database. Result of
successful authentication is Identity object, which is saved to sharedState map.
</para>
</listitem>
</varlistentry>
@@ -213,13 +214,13 @@
<module-option name="membershipType" value="member"
/>
<module-option name="groupId" value="/platform/users"
/>
</login-module>
- <login-module
code="org.exoplatform.services.security.j2ee.JBossEAP6LoginModule"
flag="required">
+ <login-module
code="org.exoplatform.services.security.j2ee.JBossAS7LoginModule"
flag="required">
<module-option name="portalContainerName"
value="portal"/>
<module-option name="realmName"
value="gatein-domain"/>
</login-module>]]>
</programlisting>
<para>
- And a configuration example with enabled SSO:
+ Configuration example with enabled SSO:
</para>
<programlisting language="XML" role="XML"><![CDATA[
<login-module
code="org.gatein.sso.integration.SSODelegateLoginModule"
flag="required">
@@ -235,7 +236,7 @@
<module-option name="membershipType" value="member" />
<module-option name="groupId" value="/platform/users"
/>
</login-module>
- <login-module
code="org.exoplatform.services.security.j2ee.JBossEAP6LoginModule"
flag="required">
+ <login-module
code="org.exoplatform.services.security.j2ee.JBossAS7LoginModule"
flag="required">
<module-option name="portalContainerName"
value="portal"/>
<module-option name="realmName"
value="gatein-domain"/>
</login-module>]]>
@@ -264,8 +265,7 @@
<formalpara
id="form-Authentication_Authorization_Intro-authenticationAppServerLevel">
<title>Authentication on Application Server Level</title>
<para>
- <remark>QUESTION: Should the following reference to Tomcat be
removed?</remark>
- Application server needs to properly recognize that user is successfully logged
and it has assigned his JAAS roles. Unfortunately this part is not standardized and is
specific for each AS. For example in JBoss Enterprise Application, you need to ensure that
JAAS Subject has assigned principal with username (UserPrincipal) and also RolesPrincipal,
which has name "Roles" and it contains list of JAAS roles. This part is
actually done in <code>JbossLoginModule.commit()</code>. In Tomcat, this flow
is little different, which means Tomcat has it is own
<literal>TomcatLoginModule</literal>.
+ Application server needs to properly recognize that user is successfully logged
and it has his JAAS roles assigned. Unfortunately this part is not standardized and is
specific for each aaplication server. For example in JBoss Enterprise Application, you
need to ensure that JAAS Subject has an assigned UserPrincipal with username and also a
RolesPrincipal, which contains a list of JAAS roles. This part is actually done in
<code>JbossAS7LoginModule.commit()</code>. In Tomcat, for example, this flow
is little different, which means Tomcat has it is own
<literal>TomcatLoginModule</literal>.
</para>
</formalpara>
<para>
@@ -307,7 +307,7 @@
]]>
</programlisting>
<para>
- Method <emphasis>validateUser</emphasis> is used to check
whether given credentials (username and password) are really valid. So it performs real
authentication. It returns back username if credentials are correct. Otherwise
LoginException is thrown.
+ Method <emphasis>validateUser</emphasis> is used to check
whether given credentials (username and password) are really valid. So it performs real
authentication. It returns a username if the credentials are correct. Otherwise
LoginException is thrown.
</para>
<para>
Method <emphasis>createIdentity</emphasis> is used to create
instance of object
<emphasis>org.exoplatform.services.security.Identity</emphasis>, which
encapsulates all important information about a single user:
@@ -320,7 +320,7 @@
</listitem>
<listitem>
<para>
- set of Memberships (MembershipEntry objects) which user belongs to.
<emphasis>Membership</emphasis> is object, which contains information about
<emphasis>membershipType</emphasis> (manager, member, validator, ... ) and
about <emphasis>group</emphasis> (/platform/users, /platform/administrators,
/partners, /organization/management/executiveBoard, ... ).
+ set of Memberships (MembershipEntry objects) which user has.
<emphasis>Membership</emphasis> is object, which contains information about
<emphasis>membershipType</emphasis> (manager, member, validator, ... ) and
about <emphasis>group</emphasis> (/platform/users, /platform/administrators,
/partners, /organization/management/executiveBoard, ... ).
</para>
</listitem>
<listitem>
@@ -386,10 +386,10 @@
<section
id="sect-Authentication_Authorization_Intro-RememberMeAuthentication">
<title>RememberMe Authentication</title>
<para>
- In default login dialog, you can notice that there is "Remember
my login" checkbox, which users can use to persist their login on his
workstation. Default validity period of RememberMe cookie is one day (it is configurable),
and so user can be logged for whole day before he need to re-authenticate again with his
credentials.
+ In default login dialog, you can notice that there is "Remember
my login" checkbox, which users can use to persist their login on his
workstation. Default validity period of RememberMe cookie is one day (it is configurable),
and so user can be logged for whole day before he need to re-authenticate.
</para>
<section
id="sect-Authentication_Authorization_Intro-RememberMeAuthentication-howDoesItWork">
- <title>How Does It Work</title>
+ <title>How It Works</title>
<itemizedlist>
<listitem>
<para>
@@ -398,12 +398,12 @@
</listitem>
<listitem>
<para>
- HTTP request like <ulink
url="http://localhost:8080/portal/login?initialURI=/portal/classic&amp;username=root&amp;password=gtn&amp;rememberme=true"/>
is sent to server.
+ HTTP request like <ulink
url="http://localhost:8080/portal/login?initialURI=/portal/classic&amp;username=root&amp;password=gtn&amp;rememberme=true"/>
is sent to server. This is not a HTTP GET request and the parameters are not encoded in
URL. The login form is submitted in a HTTP POST request to the /portal/login URL.
</para>
</listitem>
<listitem>
<para>
- Request is processed by PortalLoginController servlet. Servlet
obtains instance of <emphasis>RemindPasswordTokenService</emphasis> and save
user credentials into JCR. It generates and returns special token (key) for later use.
Then it creates cookie called <emphasis>RememberMe</emphasis> and use returned
token as value of cookie.
+ Request is processed by PortalLoginController servlet. The
servlet obtains instance of <emphasis>RemindPasswordTokenService</emphasis>
and saves user credentials into JCR. It generates and returns special token (key) for
later use. Then it creates cookie called <emphasis>RememberMe</emphasis> and
use returned token as value of cookie.
</para>
</listitem>
</itemizedlist>
Modified:
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml
===================================================================
---
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml 2013-03-01
06:46:33 UTC (rev 9191)
+++
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/BackendConfiguration.xml 2013-03-03
15:57:47 UTC (rev 9192)
@@ -110,8 +110,7 @@
<parameter>(value-param)</parameter>
</para>
<para>
- If the <literal>config</literal>
parameter is not provided, this parameter will be used to perform JNDI lookup for
IdentitySessionFactory.
- </para>
+ If the <literal>config</literal>
parameter is not provided, this parameter will be used to perform JNDI lookup for
IdentitySessionFactory.</para>
</listitem>
@@ -483,9 +482,7 @@
<section
id="sid-54264613_PicketLinkIDMintegration-PicketlinkIDMServiceImpl">
<title>PicketlinkIDMServiceImpl</title>
<para>
- The
-
<code>org.exoplatform.services.organization.idm.PicketLinkIDMServiceImpl</code>
- service has the following options:
+
The<code>org.exoplatform.services.organization.idm.PicketLinkIDMServiceImpl</code>
service has the following options:
</para>
<itemizedlist>
<listitem>
@@ -496,54 +493,37 @@
</listitem>
<listitem>
<para>
- <code>hibernate.properties</code>
- (properties-param) A list of hibernate properties used to create
SessionFactory that will be injected to JBoss Identity IDM configuration registry.
+ <code>hibernate.properties</code> (properties-param) A list of
hibernate properties used to create SessionFactory that will be injected to JBoss Identity
IDM configuration registry.
</para>
</listitem>
<listitem>
<para>
- <code>hibernate.annotations</code>
- A list of annotated classes that will be added to Hibernate configuration.
+ <code>hibernate.annotations</code> A list of annotated classes
that will be added to Hibernate configuration.
</para>
</listitem>
<listitem>
<para>
- <code>hibernate.mappings</code>
- A list of
- <code>.xml</code>
- files that will be added to hibernate configuration as mapping files.
+ <code>hibernate.mappings</code> A list of
<code>.xml</code> files that will be added to hibernate configuration as
mapping files.
</para>
</listitem>
<listitem>
<para>
- <code>jndiName</code>
- (value-param) If the 'config' parameter is not provided,
this parameter will be used to perform JNDI lookup for
- <code>IdentitySessionFactory</code>
- .
+ <code>jndiName</code> (value-param) If the
'config' parameter is not provided, this parameter will be used to
perform JNDI lookup for <code>IdentitySessionFactory</code>.
</para>
</listitem>
<listitem>
<para>
- <code>portalRealm</code>
- (value-param) The realm name that should be used to obtain proper
- <code>IdentitySession</code>
- . The default is
- <code>'PortalRealm'</code>
- .
+ <code>portalRealm</code> (value-param) The realm name that should
be used to obtain proper <code>IdentitySession</code>. The default is
<code>'PortalRealm'</code>.
</para>
</listitem>
<listitem>
<para>
- <code>apiCacheConfig</code>
- (value-param) The Infinispan configuration file with cache configuration for
PicketLink IDM API. It's different for cluster and non-cluster because Infinispan
needs to be replicated in cluster environment.
+ <code>apiCacheConfig</code> (value-param) The Infinispan
configuration file with cache configuration for PicketLink IDM API. It's
different for cluster and non-cluster because Infinispan needs to be replicated in cluster
environment.
</para>
</listitem>
<listitem>
<para>
- <code>storeCacheConfig</code>
- (value-param)
-
- The Infinispan configuration file with cache configuration for PicketLink IDM
IdentityStore. Actually it's used only for LDAP store (not used with default DB
configuration). It's different for cluster and non-cluster because Infinispan
needs to be replicated in cluster environment.
+ <code>storeCacheConfig</code> (value-param). The Infinispan
configuration file with cache configuration for PicketLink IDM IdentityStore. Actually
it's used only for LDAP store (not used with default DB configuration).
It's different for cluster and non-cluster because Infinispan needs to be
replicated in cluster environment.
</para>
</listitem>
</itemizedlist>
@@ -551,90 +531,57 @@
<section
id="sid-54264613_PicketLinkIDMintegration-PicketlinkIDMOrganizationServiceImpl">
<title>PicketlinkIDMOrganizationServiceImpl</title>
<para>
- The
-
<code>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</code>
- key is a main entry point implementing
-
<code>org.exoplatform.services.organization.OrganizationService</code>
- and is dependent on
-
<code>org.exoplatform.services.organization.idm.PicketLinkIDMService</code>
- .
+ The
<code>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</code>
key is a main entry point implementing
<code>org.exoplatform.services.organization.OrganizationService</code> and is
dependent on
<code>org.exoplatform.services.organization.idm.PicketLinkIDMService</code>.
</para>
<para>
- The
-
<code>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</code>
- service has the following options defined as fields of object-param of the
- <code>org.exoplatform.services.organization.idm.Config</code>
- type:
+
The<code>org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl</code>
service has the following options defined as fields of object-param of the
<code>org.exoplatform.services.organization.idm.Config</code> type:
</para>
<itemizedlist>
<listitem>
<para>
<code>defaultGroupType</code>
- The name of the PicketLink IDM GroupType that will be used to store groups.
The default is
- <code>'GTN_GROUP_TYPE'</code>
- .
+ The name of the PicketLink IDM GroupType that will be used to store groups.
The default is<code>'GTN_GROUP_TYPE'</code>.
</para>
</listitem>
<listitem>
<para>
- <code>rootGroupName</code>
- The name of the PicketLink IDM Group that will be used as a root parent. The
default is
- <code>'GTN_ROOT_GROUP'</code>
- .
+ <code>rootGroupName</code> The name of the PicketLink IDM Group
that will be used as a root parent. The default is
<code>'GTN_ROOT_GROUP'</code>.
</para>
</listitem>
<listitem>
<para>
- <code>passwordAsAttribute</code>
- This parameter specifies if a password should be stored using PicketLink IDM
Credential object or as a plain attribute. The default is
- <code>false</code>
- .
+ <code>passwordAsAttribute</code> This parameter specifies if a
password should be stored using PicketLink IDM Credential object or as a plain attribute.
The default is <code>false</code>.
</para>
</listitem>
<listitem>
<para>
- <code>useParentIdAsGroupType</code>
- This parameter stores the parent ID path as a group type in PicketLink IDM
for any IDs not mapped with a specific type in 'groupTypeMappings'. If
this option is set to
- <code>false</code>
- , and no mappings are provided under 'groupTypeMappings',
then only one group with the given name can exist in the portal group tree.
+ <code>useParentIdAsGroupType</code> This parameter stores the
parent ID path as a group type in PicketLink IDM for any IDs not mapped with a specific
type in 'groupTypeMappings'. If this option is set to
<code>false</code>, and no mappings are provided under
'groupTypeMappings', then only one group with the given name can exist
in the portal group tree.
</para>
</listitem>
<listitem>
<para>
<code>pathSeparator</code>
- When 'userParentIdAsGroupType is set to
- <code>true</code>
- , this value will be used to replace all "/" characters in
IDs. The "/" character is not allowed to be used in group type name in
PicketLink IDM.
+ When 'userParentIdAsGroupType is set to
<code>true</code>, this value will be used to replace all
"/" characters in IDs. The "/" character is not
allowed to be used in group type name in PicketLink IDM.
</para>
</listitem>
<listitem>
<para>
- <code>associationMembershipType</code>
- If this option is used, then each Membership, created with MembrshipType that
is equal to the value specified here, will be stored in PicketLink IDM as simple
Group-User association.
+ <code>associationMembershipType</code> If this option is used,
then each Membership, created with MembrshipType that is equal to the value specified
here, will be stored in PicketLink IDM as simple Group-User association.
</para>
</listitem>
<listitem>
<para>
- <code>groupTypeMappings</code>
- This parameter maps groups added with portal API as children of a given group
ID, and stores them with a given group type name in PicketLink IDM.
-
- If the parent ID ends with "/*", then all child groups will
have the mapped group type. Otherwise, only direct (first level) children will use this
type.
-
- This can be leveraged by LDAP if LDAP DN is configured in PicketLink IDM to
only store a specific group type. This will then store the given branch in portal group
tree, while all other groups will remain in the database.
+ <code>groupTypeMappings</code> This parameter maps groups added
with portal API as children of a given group ID, and stores them with a given group type
name in PicketLink IDM. If the parent ID ends with "/*", then all child
groups will have the mapped group type. Otherwise, only direct (first level) children will
use this type. This can be leveraged by LDAP if LDAP DN is configured in PicketLink IDM to
only store a specific group type. This will then store the given branch in portal group
tree, while all other groups will remain in the database.
</para>
</listitem>
<listitem>
<para>
- <code>forceMembershipOfMappedTypes</code>
- Groups stored in PicketLink IDM with a type mapped in
'groupTypeMappings' will automatically be members under the mapped
parent. Group relationships linked by PicketLink IDM group association will not be
necessary.
-
- This parameter can be set to false if all groups are added via portal APIs.
This may be useful with LDAP configuration as, when set to true, it will make every entry
added to LDAP appear in portal. This, however, is not true for entries added via JBoss
Portal Platform management user interface.
+ <code>forceMembershipOfMappedTypes</code> Groups stored in
PicketLink IDM with a type mapped in 'groupTypeMappings' will
automatically be members under the mapped parent. Group relationships linked by PicketLink
IDM group association will not be necessary. This parameter can be set to false if all
groups are added via portal APIs. This may be useful with LDAP configuration as, when set
to true, it will make every entry added to LDAP appear in portal. This, however, is not
true for entries added via JBoss Portal Platform management user interface.
</para>
</listitem>
<listitem>
<para>
- <code>ignoreMappedMembershipType</code>
- If "associationMembershipType" option is used, and this
option is set to true, then Membership with MembershipType configured to be stored as
PicketLink IDM association will not be stored as PicketLink IDM Role.
+ <code>ignoreMappedMembershipType</code> If
"associationMembershipType" option is used, and this option is set to
true, then Membership with MembershipType configured to be stored as PicketLink IDM
association will not be stored as PicketLink IDM Role.
</para>
</listitem>
</itemizedlist>
Modified:
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml
===================================================================
---
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-03-01
06:46:33 UTC (rev 9191)
+++
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/PasswordEncryption.xml 2013-03-03
15:57:47 UTC (rev 9192)
@@ -16,23 +16,17 @@
<para>
Default implementation of
<code>CredentialEncoder</code>
- is using password hashing with MD5 algorithm and storing those MD5 hashes in
database. It does not use any salting of passwords. This is not safest solution, but
it's backward compatible with previous releases of JBoss Portal Platform before
version 3.5, where MD5 password hashing was only possible encoding form. So if you migrate
from older release of JBoss Portal Platform, your users will be still able to
authenticate.
+ is using password hashing with MD5 algorithm and storing those MD5 hashes in
database. It does not use any salting of passwords. This is not safest solution, but
it's backward compatible with previous releases of JBoss Portal Platform before
version 6, where MD5 password hashing was the only possible encoding form. So if you
migrate from older release of JBoss Portal Platform, your users will still be able to
authenticate.
</para>
- <para>However if you are starting from fresh database (no migration from
previous JBoss Portal Platform release), you may increase security by using better hashing
algorithm and especially by enable password salting. See below for details.</para>
+ <para>However if you are starting from a fresh database (no migration from
previous JBoss Portal Platform release), you may increase security by using better hashing
algorithm and especially by enabling password salting. See below for
details.</para>
<section
id="sid-54264610_PasswordEncryption-ChoosingCredentialEncoderimplementation">
<title>Choosing CredentialEncoder Implementation</title>
<para>
- The implementation of CredentialEncoder is configured in file
-
<code>JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/picketlink-idm/picketlink-idm-config.xml</code>
- . Usually the most important are options of realm
- <code>idm_portal</code>
- starting with prefix
- <code>credentialEncoder.</code>
- . Possible implementations are:
+The implementation of CredentialEncoder is configured in file
<code>JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/picketlink-idm/picketlink-idm-config.xml</code>.
Usually the most important options are the options of the
<code>idm_portal</code> realm starting with
<code>credentialEncoder</code> prefix. Possible implementations are
HashingEncoder, DatabaseReadingSaltEncoder, and FileReadingSaltEncoder.
</para>
<section id="sid-54264610_PasswordEncryption-HashingEncoder">
<title>HashingEncoder</title>
- <para>This is the default choice. It uses only hashing of passwords with
MD5 algorithm without salting. As mentioned previously, it's not safest solution
but it's backward compatible with previous JBoss Portal Platform releases, so
there are no issues with database migration from previous release. Configuration looks
like this:</para>
+ <para>This is the default choice. It uses only hashing of passwords with
MD5 algorithm without salting. As mentioned previously, it is not the safest solution but
it's backward compatible with the previous JBoss Portal Platform releases, so
there are no issues with database migration. Configuration looks like this:</para>
<informalexample>
<programlisting>
<option>
@@ -48,7 +42,7 @@
</section>
<section
id="sid-54264610_PasswordEncryption-DatabaseReadingSaltEncoder">
<title>DatabaseReadingSaltEncoder</title>
- <para>This implementation provides salting of password in addition to
hashing. The salt is unique for each user, so it's much more complicated to
decrypt password via brute force, if some attacker steal encoded passwords from your
database. The salt is generated randomly for each user and stored in PicketLink IDM
database as attribute. Random generation of salt ensure that all users have different
salts, so even if two users have same password, the encoded password in database will be
different for them. Here is configuration example, which is using SHA-256 algorithm for
hashing (more secure than MD5) and algorithm SHA1PRNG for generation of random
salts.</para>
+ <para>This implementation provides salting of password in addition to
hashing. The salt is unique for each user, so it's much more complicated to
decrypt password via brute force, if some attacker steals encoded passwords from your
database. The salt is generated randomly for each user and stored in PicketLink IDM
database as an attribute. Random generation of salt ensures that all users have different
salts, so even if two users have the same password, the encoded password in database will
be different for them. Here is configuration example, which is using SHA-256 algorithm for
hashing (more secure than MD5) and algorithm SHA1PRNG for generation of random
salts.</para>
<informalexample>
<programlisting>
<option>
@@ -69,11 +63,7 @@
<section
id="sid-54264610_PasswordEncryption-FileReadingSaltEncoder">
<title>FileReadingSaltEncoder</title>
<para>
- It also uses hashing and salting, so it's similar like previous
encoder. But it's theoretically even more secure, because salts are not stored in
PicketLink IDM database together with passwords. Salt of each user is generated from
- <emphasis role="italics">saltPrefix</emphasis>
- and user's username. And
- <emphasis role="italics">saltPrefix</emphasis>
- is read from some file in your file system. Configuration can look like this:
+ The FileReadingSaltEncoder also uses hashing and salting, so it's
similar to the previous encoder. But it's theoretically even more secure, because
salts are not stored in PicketLink IDM database together with passwords. Salt of each user
is generated from <emphasis role="italics">saltPrefix</emphasis> and
user's username. And <emphasis
role="italics">saltPrefix</emphasis> is read from some file in your
file system. Configuration can look like this:
</para>
<informalexample>
<programlisting>
@@ -92,29 +82,15 @@
</programlisting>
</informalexample>
<para>
- Please note that specified file
- <code>/salt/mysalt.txt</code>
- must exist and must be readable by user, which executed JBoss Portal Platform.
But file should be properly secured to not be readable by every user of your OS. The file
can have some random content phrase, for example
- <emphasis
role="italics">a4564dac2aasddsklklkajdgnioiow</emphasis>
- .
- </para>
+ Please note that specified file <code>/salt/mysalt.txt</code> must
exist and must be readable by user, which executed JBoss Portal Platform. The file should
be properly secured so that it is readable by every user of your OS. The content of the
file can be a random phrase, such as <emphasis
role="italics">a4564dac2aasddsklklkajdgnioiow</emphasis>.
+ </para>
<para>
- So the
- <code>FileReadingSaltEncoder</code>
- is probably most secure of all options, but in addition to
- <code>DatabaseReadingSaltEncoder</code>
- you need to set the file with salt.
+So the <code>FileReadingSaltEncoder</code>is probably the most secure of all
options, but in addition to <code>DatabaseReadingSaltEncoder</code>, you need
to set the file with salt.
</para>
<important>
<title>Important</title>
<para>
- The
- <code>CredentialEncoder</code>
- from above is actually used only for encoding of passwords in PicketLink IDM
database. It's not used for LDAP. PicketLink IDM LDAP implementation (
- <code>LDAPIdentityStore</code>
- ) is sending passwords to LDAP server in plain form, because password
encoding is usually provided by LDAP server itself. For example OpenDS 2 is using SHA1
based hashing of passwords with random generation of user salt (so actually something
similar to our
- <code>DatabaseReadingSaltEncoder</code>
- implementation).
+ The <code>CredentialEncoder</code> from above is actually used
only for encoding of passwords in PicketLink IDM database. It's not used for
LDAP. PicketLink IDM LDAP implementation (<code>LDAPIdentityStore</code>) is
sending passwords to LDAP server in plain form, because password encoding is usually
provided by LDAP server itself. For example OpenDS 2 is using SHA1 based hashing of
passwords with random generation of user salt (so actually something similar to our
<code>DatabaseReadingSaltEncoder</code> implementation).
</para>
</important>
</section>
@@ -139,38 +115,38 @@
</listitem>
<listitem>
<para>
- Passwords can be encoded prior to being saved to the JCR. This option
requires administrators to provide a custom subclass of
<parameter>org.exoplatform.web.security.security.AbstractCodec</parameter> and
set up a codec implementation with <parameter>CookieTokenService</parameter>:
+ Passwords can be encoded prior to being saved to the JCR. This option requires
administrators to provide a custom subclass of
<parameter>org.exoplatform.web.security.security.AbstractCodec</parameter> and
set up a codec implementation with <parameter>CookieTokenService</parameter>:
</para>
<procedure
id="proc-Reference_Guide-Password_Encryption-Encrypt_Password_in_JCR">
<title>Encrypt Password in JCR</title>
<step>
<para>
- Create a Java class similar to:
+ Create a Java class similar to:
</para>
<programlisting language="Java"
role="Java"><xi:include
xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../extras/Authentication_Identity/ExampleCodec.java"
parse="text"/></programlisting>
</step>
<step>
<para>
- Compile the class and package it into a jar file. For this
example we will call the jar file <filename>codec-example.jar</filename>.
+ Compile the class and package it into a jar file. For this example we will
call the jar file <filename>codec-example.jar</filename>.
</para>
</step>
<step>
<para>
- Create a
<filename>conf/portal/configuration.xml</filename> file within the
<filename>codec-example.jar</filename> similar to the example below. This
allows the portal kernel to find and use the new codec implementation.
+ Create a <filename>conf/portal/configuration.xml</filename> file within the
<filename>codec-example.jar</filename> similar to the example below. This
allows the portal kernel to find and use the new codec implementation.
</para>
<programlisting language="XML"
role="XML"><xi:include
xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../extras/Authentication_Identity/configuration.xml"
parse="text"/></programlisting>
</step>
<step>
<para>
- Deploy the <filename>codec-example.jar</filename>
into the
<filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/lib/</filename>
directory.
+ Deploy the <filename>codec-example.jar</filename> into the
<filename><replaceable>JPP_DIST</replaceable>/gatein/gatein.ear/lib/</filename>
directory.
</para>
</step>
<step>
<para>
- Start (or restart) JBoss Portal Platform.
+ Start (or restart) JBoss Portal Platform.
</para>
<para>
- Any passwords written to the JCR will now be encoded and not
plain text.
+ Any passwords written to the JCR will now be encoded and not plain text.
</para>
</step>
</procedure>
Modified:
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2.xml
===================================================================
(Binary files differ)
Modified:
epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity/SAML2_Salesforce_and_Google_Integration.xml
===================================================================
(Binary files differ)