From do-not-reply at jboss.org Sun Mar 3 10:57:48 2013 Content-Type: multipart/mixed; boundary="===============3710774959652789753==" MIME-Version: 1.0 From: do-not-reply at jboss.org To: gatein-commits at lists.jboss.org Subject: [gatein-commits] gatein SVN: r9192 - in epp/docs/branches/6.0/Reference_Guide/en-US: modules/AuthenticationAndIdentity and 1 other directory. Date: Sun, 03 Mar 2013 10:57:47 -0500 Message-ID: <201303031557.r23FvlU6026015@svn01.web.mwc.hst.phx2.redhat.com> --===============3710774959652789753== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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/AuthenticationAndIde= ntity/AccessingUserProfile.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIde= ntity/AuthenticationAuthorizationOverview.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIde= ntity/BackendConfiguration.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIde= ntity/PasswordEncryption.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIde= ntity/SAML2.xml epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIde= ntity/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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-0= 3-01 06:46:33 UTC (rev 9191) +++ epp/docs/branches/6.0/Reference_Guide/en-US/Revision_History.xml 2013-0= 3-03 15:57:47 UTC (rev 9192) @@ -7,6 +7,20 @@ Revision History + + 6.0.0-54 + Mon Mar 4 2013 + + Aakanksha + Singh + + + + + BZ#911516,856448,856430 - Incorporated new QE Review c= omments. + + + 6.0.0-53 Wed Feb 27 2013 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Authenticatio= nAndIdentity/AccessingUserProfile.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/AccessingUserProfile.xml 2013-03-01 06:46:33 UTC (rev 9191) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/AccessingUserProfile.xml 2013-03-03 15:57:47 UTC (rev 9192) @@ -22,6 +22,6 @@ - Both alternatives are probably better then {{OrganizationService orgS= ervice =3D getApplicationComponent(OrganizationService.class)}} because you= can use them from your own portlets or servlet/portlet filters. The varian= t with {{getApplicationComponent}} works only from WebUI. + Both alternatives are probably better than OrganizationService = orgService =3D getApplicationComponent(OrganizationService.class) be= cause you can use them from your own portlets or servlet/portlet filters. T= he variant with getApplicationComponent works only from = WebUI. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Authenticatio= nAndIdentity/AuthenticationAuthorizationOverview.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/AuthenticationAuthorizationOverview.xml 2013-03-01 06:46:33 UTC (rev= 9191) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/AuthenticationAuthorizationOverview.xml 2013-03-03 15:57:47 UTC (rev= 9192) @@ -49,9 +49,10 @@ Authentication workflow consists of HTTP requests and redirect= s which include handshakes. Currently only Servlet 3.0 containers are suppo= rted, so authentication is triggered programmatically from Servlet API. - In JPP_DIST/gatein/gatein.e= ar/portal.war/WEB-INF/web.xml, authentication is triggered by ac= cessing a secured URL _/dologin_: + In JPP_DIST/gatein/gatein.e= ar/portal.war/WEB-INF/web.xml, authentication is triggered by ac= cessing a secured URL /dologin: - <security-constraint> + +<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 http://localhost:8080/portal/do= login) will directly trigger J2EE authentication in the case that t= he user is not already logged in. - Access to this URL also means that the user needs to be in th= e JAAS group users, otherwise they can authenticate bu= t will receive an HTTP error: 403 Forbidden, for examp= le. + Access to this URL means that the user needs to be in the JAA= S group users, otherwise they can authenticate but wil= l receive an HTTP error: 403 Forbidden. In the next part of the file we can see that authentication is= FORM based and it starts by redirection to /login URL= , which is mapped to LoginServlet. @@ -101,7 +102,7 @@ Changes to the appearance of this login page can be made in th= is JSP file. Alternatively you can create an extension and override this pa= ge via extension if you don't want to edit it directly. You can also c= hange images or CSS placed in JPP_DIST= /gatein/gatein.ear/login/skin. - After a user submits the login form, they are redirected to th= e login URL: http:= //localhost:8080/portal/login?username=3Droot&password=3Dgtn&initia= lURI=3D/portal/private/classic. = + After a user submits the login form, the LoginServlet will sto= re credentials and trigger WCI login, which delegates to Servlet API (metho= d HttpServletRequest.login(String username, String password) available in S= ervlet 3.0) and additionally triggers WCI Authentication listeners. Login t= hrough Servlet API delegates to JAAS. This URL is mapped to LoginServlet servlet= , which stores credentials and redirects again to LoginServlet. LoginServlet triggers WCI login, which delegates to Servlet API (m= ethod HttpServletRequest.login(String username, String password) available = in Servlet 3.0) and additionally triggers WCI Authentication listeners. Log= in through Servlet API delegates to JAAS. @@ -125,7 +126,7 @@ - + @@ -149,22 +150,22 @@ SSODelegateLoginModule - It is useful only if SSO authentication is enabled (disabl= ed by default. It can be enabled through properties in configuration.proper= ties file and in this case it delegates the work to another real login modu= le for SSO integration. If SSO is disabled, SSODelegateLoginModule is simpl= y ignored. See properties details for more details. If SSO is used and SSO= authentication succeed, the special Identity object will be created and sa= ved into shared state map (Map, which is shared between all login modules),= so that this Identity object can be used by JBoss Enterprise Application P= latform 6 LoginModule or other login modules in the JAAS chain. + It is useful only if SSO authentication is enabled (disabl= ed by default). SSO authentication can be enabled through properties in configuration.properties file and it delegates the work t= o another real login module for SSO integration. If SSO is disabled, SSODelegateLoginModule is simply ignored. See properties f= or more details. If SSO is used and SSO authentication succeeds, the specia= l 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 use= d by JBossAS7LoginModule or other login modules in the JAAS chain. - JBoss Enterprise Application Platform 6 LoginModule + JBossAS7LoginModule - Most important login module, which is normally used to perf= orm whole authentication by itself. First it checks if Identity object has = been already created and saved into sharedState map by previous login modul= es (like SSODelegateLoginModule, CustomMembershipLoginModule or SharedState= LoginModule). If not, it triggers real authentication of user with usage of= Authenticator interface and it will use Authentication.validateUser(Creden= tial[] credentials) which performs real authentication of username and pass= word against OrganizationService and portal identity database. See for details about Authenticator and about Identity objects. - In the JBoss Enterprise Application Platform 6 LoginModu= le.commit method, the Identity object is registered to IdentityRegistry, wh= ich will be used later for authorization. Also some JAAS principals (UserPr= incipal 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 perf= orm the whole authentication by itself. First it checks if Identity object = has been already created and saved into sharedState map by previous login m= odules (like SSODelegateLoginModule, CustomMembershipLoginModule or SharedS= tateLoginModule). If not, it triggers real authentication of user with usag= e of Authenticator interface and it will use Authentication.valid= ateUser(Credential[] credentials) which performs real authentica= tion of username and password against OrganizationService and portal identi= ty database. See for details about Authenticator and about = Identity objects. + In the JBossAS7LoginModule.commit m= ethod, 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. - Some other login modules are not active by default, but can be ad= ded them if you find them useful. + Some other login modules are not active by default, but can be ad= ded if needed. @@ -174,7 +175,7 @@ Special login module, which can be used to add a user to e= xisting groups during a successful login of this user. The group name is co= nfigurable and by default is /platform/users group. This login module is no= t used because in normal environment, users are already in the /platform/us= ers group. It is useful only for some special setups like read-only LDAP, w= here 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 authori= zation. - Note that the CustomMembershipLoginModule can't be the= first login module in the LoginModule chain because it assumes that the Id= entity object is already available in shared state. So there are two possib= le cases. For an non-SSO case, you may need to chain this LM with other log= in modules, which can be used to establish Identity and add it into shared = state. Those LM can be InitSharedStateLoginModule and SharedStateLoginModul= e. For an SSO case, you can add CustomMembershipLoginModule between SSODele= gateLoginModule 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 Id= entity object is already available in shared state. So there are two possib= le 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 int= o shared state. Those login modules can be InitSharedStateLoginMo= dule and SharedStateLoginModule. For an SSO= case, you can add CustomMembershipLoginModule between= SSODelegateLoginModule and JBossAS7LoginModule. @@ -190,7 +191,7 @@ SharedStateLoginModule - It reads username and password from sharedState map fr= om 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 OrganizationS= ervice 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 fr= om attributes javax.security.auth.login.name and javax.security.auth.login.password. Then it calls Authenticator= .validateUser(Credential[] credentials), to perform authentication of usern= ame and password against OrganizationService and portal identity database. = Result of successful authentication is Identity object, which is saved to s= haredState map. @@ -213,13 +214,13 @@ - + ]]> - And a configuration example with enabled SSO: + Configuration example with enabled SSO: @@ -235,7 +236,7 @@ - + ]]> @@ -264,8 +265,7 @@ Authentication on Application Server Level - QUESTION: Should the following reference to Tomcat be remo= ved? - Application server needs to properly recognize that user is succ= essfully logged and it has assigned his JAAS roles. Unfortunately this part= is not standardized and is specific for each AS. For example in JBoss Ente= rprise Application, you need to ensure that JAAS Subject has assigned princ= ipal with username (UserPrincipal) and also RolesPrincipal, which has name = "Roles" and it contains list of JAAS roles. This part is actually= done in JbossLoginModule.commit(). In Tomcat, this flow is li= ttle different, which means Tomcat has it is own TomcatLoginModule= . + Application server needs to properly recognize that user is succ= essfully logged and it has his JAAS roles assigned. Unfortunately this part= is not standardized and is specific for each aaplication server. For examp= le in JBoss Enterprise Application, you need to ensure that JAAS Subject ha= s an assigned UserPrincipal with username and also a RolesPrincipal, which = contains a list of JAAS roles. This part is actually done in JbossAS7= LoginModule.commit(). In Tomcat, for example, this flow is little di= fferent, which means Tomcat has it is own TomcatLoginModule. @@ -307,7 +307,7 @@ ]]> - Method validateUser is used to check w= hether given credentials (username and password) are really valid. So it pe= rforms real authentication. It returns back username if credentials are cor= rect. Otherwise LoginException is thrown. + Method validateUser is used to check w= hether given credentials (username and password) are really valid. So it pe= rforms real authentication. It returns a username if the credentials are co= rrect. Otherwise LoginException is thrown. Method createIdentity is used to creat= e instance of object org.exoplatform.services.security.Identity, which encapsulates all important information about a single user: @@ -320,7 +320,7 @@ - set of Memberships (MembershipEntry objects) which us= er belongs to. Membership is object, which contains in= formation about membershipType (manager, member, valid= ator, ... ) and about group (/platform/users, /platfor= m/administrators, /partners, /organization/management/executiveBoard, ... ). + set of Memberships (MembershipEntry objects) which us= er has. Membership is object, which contains informati= on about membershipType (manager, member, validator, .= .. ) and about group (/platform/users, /platform/admin= istrators, /partners, /organization/management/executiveBoard, ... ). @@ -386,10 +386,10 @@
RememberMe Authentication - In default login dialog, you can notice that there is "= ;Remember my login" checkbox, which users can use to persist their log= in 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 log= in 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.
- How Does It Work + How It Works @@ -398,12 +398,12 @@ - HTTP request like is sent to server. + HTTP request like is sent to server. This is n= ot 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. - Request is processed by PortalLoginController serv= let. Servlet obtains instance of RemindPasswordTokenService and save user credentials into JCR. It generates and returns special = token (key) for later use. Then it creates cookie called Remember= Me and use returned token as value of cookie. + Request is processed by PortalLoginController serv= let. The servlet obtains instance of RemindPasswordTokenService and saves user credentials into JCR. It generates and returns spe= cial token (key) for later use. Then it creates cookie called Rem= emberMe and use returned token as value of cookie. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Authenticatio= nAndIdentity/BackendConfiguration.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/BackendConfiguration.xml 2013-03-01 06:46:33 UTC (rev 9191) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/BackendConfiguration.xml 2013-03-03 15:57:47 UTC (rev 9192) @@ -110,8 +110,7 @@ (value-param) - If the config param= eter is not provided, this parameter will be used to perform JNDI lookup fo= r IdentitySessionFactory. - + If the config param= eter is not provided, this parameter will be used to perform JNDI lookup fo= r IdentitySessionFactory. = = @@ -483,9 +482,7 @@
PicketlinkIDMServiceImpl - The - org.exoplatform.services.organization.idm.PicketLinkIDMServi= ceImpl - service has the following options: + Theorg.exoplatform.services.organization.idm.PicketLinkIDMSe= rviceImpl service has the following options: @@ -496,54 +493,37 @@ - hibernate.properties - (properties-param) A list of hibernate properties used to crea= te SessionFactory that will be injected to JBoss Identity IDM configuration= registry. + hibernate.properties (properties-param) A list of= hibernate properties used to create SessionFactory that will be injected t= o JBoss Identity IDM configuration registry. - hibernate.annotations - A list of annotated classes that will be added to Hibernate co= nfiguration. + hibernate.annotations A list of annotated classes= that will be added to Hibernate configuration. - hibernate.mappings - A list of - .xml - files that will be added to hibernate configuration as mapping= files. + hibernate.mappings A list of .xml fi= les that will be added to hibernate configuration as mapping files. - jndiName - (value-param) If the 'config' parameter is not provi= ded, this parameter will be used to perform JNDI lookup for - IdentitySessionFactory - . + jndiName (value-param) If the 'config' = parameter is not provided, this parameter will be used to perform JNDI look= up for IdentitySessionFactory. - portalRealm - (value-param) The realm name that should be used to obtain pro= per - IdentitySession - . The default is - 'PortalRealm' - . + portalRealm (value-param) The realm name that sho= uld be used to obtain proper IdentitySession. The default is <= code>'PortalRealm'. - apiCacheConfig - (value-param) The Infinispan configuration file with cache con= figuration for PicketLink IDM API. It's different for cluster and non-= cluster because Infinispan needs to be replicated in cluster environment. + apiCacheConfig (value-param) The Infinispan confi= guration file with cache configuration for PicketLink IDM API. It's di= fferent for cluster and non-cluster because Infinispan needs to be replicat= ed in cluster environment. - storeCacheConfig - (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 a= nd non-cluster because Infinispan needs to be replicated in cluster environ= ment. + storeCacheConfig (value-param). The Infinispan co= nfiguration file with cache configuration for PicketLink IDM IdentityStore.= Actually it's used only for LDAP store (not used with default DB conf= iguration). It's different for cluster and non-cluster because Infinis= pan needs to be replicated in cluster environment. @@ -551,90 +531,57 @@
PicketlinkIDMOrganizationServiceImpl - The - org.exoplatform.services.organization.idm.PicketLinkIDMOrgan= izationServiceImpl - key is a main entry point implementing - org.exoplatform.services.organization.OrganizationService - and is dependent on - org.exoplatform.services.organization.idm.PicketLinkIDMServi= ce - . + The org.exoplatform.services.organization.idm.PicketLinkIDMO= rganizationServiceImpl key is a main entry point implementing = org.exoplatform.services.organization.OrganizationService and is dep= endent on org.exoplatform.services.organization.idm.PicketLinkIDMServ= ice. - The - org.exoplatform.services.organization.idm.PicketLinkIDMOrgan= izationServiceImpl - service has the following options defined as fields of object-para= m of the - org.exoplatform.services.organization.idm.Config - type: + Theorg.exoplatform.services.organization.idm.PicketLinkIDMOr= ganizationServiceImpl service has the following options defined as f= ields of object-param of the org.exoplatform.services.organization.id= m.Config type: defaultGroupType - The name of the PicketLink IDM GroupType that will be used to = store groups. The default is - 'GTN_GROUP_TYPE' - . + The name of the PicketLink IDM GroupType that will be used to = store groups. The default is'GTN_GROUP_TYPE'. - rootGroupName - The name of the PicketLink IDM Group that will be used as a ro= ot parent. The default is - 'GTN_ROOT_GROUP' - . + rootGroupName The name of the PicketLink IDM Grou= p that will be used as a root parent. The default is 'GTN_ROOT_G= ROUP'. - passwordAsAttribute - This parameter specifies if a password should be stored using = PicketLink IDM Credential object or as a plain attribute. The default is - false - . + passwordAsAttribute This parameter specifies if a= password should be stored using PicketLink IDM Credential object or as a p= lain attribute. The default is false. - useParentIdAsGroupType - This parameter stores the parent ID path as a group type in Pi= cketLink IDM for any IDs not mapped with a specific type in 'groupType= Mappings'. If this option is set to - false - , and no mappings are provided under 'groupTypeMappings&a= pos;, then only one group with the given name can exist in the portal group= tree. + useParentIdAsGroupType This parameter stores the = parent ID path as a group type in PicketLink IDM for any IDs not mapped wit= h a specific type in 'groupTypeMappings'. If this option is set t= o false, and no mappings are provided under 'groupTypeMap= pings', then only one group with the given name can exist in the porta= l group tree. pathSeparator - When 'userParentIdAsGroupType is set to - true - , this value will be used to replace all "/" charact= ers in IDs. The "/" character is not allowed to be used in group = type name in PicketLink IDM. + When 'userParentIdAsGroupType is set to true= , this value will be used to replace all "/" characters in IDs. T= he "/" character is not allowed to be used in group type name in = PicketLink IDM. - associationMembershipType - If this option is used, then each Membership, created with Mem= brshipType that is equal to the value specified here, will be stored in Pic= ketLink IDM as simple Group-User association. + associationMembershipType If this option is used,= then each Membership, created with MembrshipType that is equal to the valu= e specified here, will be stored in PicketLink IDM as simple Group-User ass= ociation. - groupTypeMappings - This parameter maps groups added with portal API as children o= f a given group ID, and stores them with a given group type name in PicketL= ink IDM. - = - If the parent ID ends with "/*", then all child grou= ps will have the mapped group type. Otherwise, only direct (first level) ch= ildren will use this type. - = - This can be leveraged by LDAP if LDAP DN is configured in Pick= etLink IDM to only store a specific group type. This will then store the gi= ven branch in portal group tree, while all other groups will remain in the = database. + groupTypeMappings This parameter maps groups adde= d with portal API as children of a given group ID, and stores them with a g= iven group type name in PicketLink IDM. If the parent ID ends with "/*= ", then all child groups will have the mapped group type. Otherwise, o= nly 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 specifi= c group type. This will then store the given branch in portal group tree, w= hile all other groups will remain in the database. - forceMembershipOfMappedTypes - Groups stored in PicketLink IDM with a type mapped in 'gr= oupTypeMappings' will automatically be members under the mapped parent= . Group relationships linked by PicketLink IDM group association will not b= e 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 tr= ue, 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 in= terface. + forceMembershipOfMappedTypes Groups stored in Pic= ketLink IDM with a type mapped in 'groupTypeMappings' will automa= tically be members under the mapped parent. Group relationships linked by P= icketLink IDM group association will not be necessary. This parameter can b= e 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 adde= d to LDAP appear in portal. This, however, is not true for entries added vi= a JBoss Portal Platform management user interface. - ignoreMappedMembershipType - If "associationMembershipType" option is used, and t= his option is set to true, then Membership with MembershipType configured t= o be stored as PicketLink IDM association will not be stored as PicketLink = IDM Role. + ignoreMappedMembershipType If "associationMe= mbershipType" option is used, and this option is set to true, then Mem= bership with MembershipType configured to be stored as PicketLink IDM assoc= iation will not be stored as PicketLink IDM Role. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Authenticatio= nAndIdentity/PasswordEncryption.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/PasswordEncryption.xml 2013-03-01 06:46:33 UTC (rev 9191) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/PasswordEncryption.xml 2013-03-03 15:57:47 UTC (rev 9192) @@ -16,23 +16,17 @@ Default implementation of CredentialEncoder - is using password hashing with MD5 algorithm and storing those MD5 h= ashes in database. It does not use any salting of passwords. This is not sa= fest solution, but it's backward compatible with previous releases of = JBoss Portal Platform before version 3.5, where MD5 password hashing was on= ly possible encoding form. So if you migrate from older release of JBoss Po= rtal Platform, your users will be still able to authenticate. + is using password hashing with MD5 algorithm and storing those MD5 h= ashes in database. It does not use any salting of passwords. This is not sa= fest 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. - However if you are starting from fresh database (no migration fr= om previous JBoss Portal Platform release), you may increase security by us= ing better hashing algorithm and especially by enable password salting. See= below for details. + 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.
Choosing CredentialEncoder Implementation - The implementation of CredentialEncoder is configured in file - JPP_HOME/gatein/gatein.ear/portal.war/WEB-INF/conf/organizat= ion/picketlink-idm/picketlink-idm-config.xml - . Usually the most important are options of realm - idm_portal - starting with prefix - credentialEncoder. - . Possible implementations are: +The implementation of CredentialEncoder is configured in file JPP_HO= ME/gatein/gatein.ear/portal.war/WEB-INF/conf/organization/picketlink-idm/pi= cketlink-idm-config.xml. Usually the most important options are the = options of the idm_portal realm starting with credential= Encoder prefix. Possible implementations are HashingEncoder, Databas= eReadingSaltEncoder, and FileReadingSaltEncoder.
HashingEncoder - This is the default choice. It uses only hashing of password= s with MD5 algorithm without salting. As mentioned previously, it's no= t safest solution but it's backward compatible with previous JBoss Por= tal Platform releases, so there are no issues with database migration from = previous release. Configuration looks like this: + This is the default choice. It uses only hashing of password= s with MD5 algorithm without salting. As mentioned previously, it is not th= e 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: <option> @@ -48,7 +42,7 @@
DatabaseReadingSaltEncoder - This implementation provides salting of password in addition= to hashing. The salt is unique for each user, so it's much more compl= icated 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 sa= lt ensure that all users have different salts, so even if two users have sa= me password, the encoded password in database will be different for them. H= ere is configuration example, which is using SHA-256 algorithm for hashing = (more secure than MD5) and algorithm SHA1PRNG for generation of random salt= s. + This implementation provides salting of password in addition= to hashing. The salt is unique for each user, so it's much more compl= icated 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 o= f salt ensures that all users have different salts, so even if two users ha= ve the same password, the encoded password in database will be different fo= r them. Here is configuration example, which is using SHA-256 algorithm for= hashing (more secure than MD5) and algorithm SHA1PRNG for generation of ra= ndom salts. <option> @@ -69,11 +63,7 @@
FileReadingSaltEncoder - It also uses hashing and salting, so it's similar like prev= ious encoder. But it's theoretically even more secure, because salts a= re not stored in PicketLink IDM database together with passwords. Salt of e= ach user is generated from - saltPrefix - and user's username. And - saltPrefix - is read from some file in your file system. Configuration can lo= ok like this: + The FileReadingSaltEncoder also uses hashing and salting, so it&= apos;s similar to the previous encoder. But it's theoretically even mo= re secure, because salts are not stored in PicketLink IDM database together= with passwords. Salt of each user is generated from saltPrefix and user's username. And saltPrefix is read from some file in your file system. = Configuration can look like this: @@ -92,29 +82,15 @@ - Please note that specified file - /salt/mysalt.txt - must exist and must be readable by user, which executed JBoss Po= rtal Platform. But file should be properly secured to not be readable by ev= ery user of your OS. The file can have some random content phrase, for exam= ple - a4564dac2aasddsklklkajdgnioiow - . - + Please note that specified file /salt/mysalt.txt mu= st 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 a4564dac2aasddsklklkajdgnioiow. + - So the - FileReadingSaltEncoder - is probably most secure of all options, but in addition to - DatabaseReadingSaltEncoder - you need to set the file with salt. +So the FileReadingSaltEncoderis probably the most secure of a= ll options, but in addition to DatabaseReadingSaltEncoder, you= need to set the file with salt. Important - The - CredentialEncoder - from above is actually used only for encoding of passwords in = PicketLink IDM database. It's not used for LDAP. PicketLink IDM LDAP i= mplementation ( - LDAPIdentityStore - ) is sending passwords to LDAP server in plain form, because p= assword encoding is usually provided by LDAP server itself. For example Ope= nDS 2 is using SHA1 based hashing of passwords with random generation of us= er salt (so actually something similar to our - DatabaseReadingSaltEncoder - implementation). + The CredentialEncoder from above is actually used= only for encoding of passwords in PicketLink IDM database. It's not u= sed for LDAP. PicketLink IDM LDAP implementation (LDAPIdentityStore) 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 DatabaseReadingSaltEncoder implementation).
@@ -139,38 +115,38 @@ - Passwords can be encoded prior to being saved to the JCR. = This option requires administrators to provide a custom subclass of org.exoplatform.web.security.security.AbstractCodec and set= up a codec implementation with CookieTokenService: + Passwords can be encoded prior to being saved to the JCR. This opt= ion requires administrators to provide a custom subclass of org.= exoplatform.web.security.security.AbstractCodec and set up a co= dec implementation with CookieTokenService: Encrypt Password in JCR - Create a Java class similar to: + Create a Java class similar to: - Compile the class and package it into a jar file. = For this example we will call the jar file codec-example.jar. + Compile the class and package it into a jar file. For this e= xample we will call the jar file codec-example.jar. - Create a conf/portal/configuration.xml file within the codec-example.jar similar to= the example below. This allows the portal kernel to find and use the new c= odec implementation. + Create a conf/portal/configuration.xml file within t= he codec-example.jar similar to the example below. Thi= s allows the portal kernel to find and use the new codec implementation. - Deploy the codec-example.jar = into the JPP_DIST/gatein/gatein.ear/li= b/ directory. + Deploy the codec-example.jar into the <= filename>JPP_DIST/gatein/gatein.ear/lib/ directory. - Start (or restart) JBoss Portal Platform. + Start (or restart) JBoss Portal Platform. - Any passwords written to the JCR will now be encod= ed and not plain text. + Any passwords written to the JCR will now be encoded and not = plain text. Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Authenticatio= nAndIdentity/SAML2.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (Binary files differ) Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/Authenticatio= nAndIdentity/SAML2_Salesforce_and_Google_Integration.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (Binary files differ) --===============3710774959652789753==--