From do-not-reply at jboss.org Sun Jan 8 18:45:53 2012
Content-Type: multipart/mixed; boundary="===============3456302768801453300=="
MIME-Version: 1.0
From: do-not-reply at jboss.org
To: gatein-commits at lists.jboss.org
Subject: [gatein-commits] gatein SVN: r8279 -
epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndIdentity.
Date: Sun, 08 Jan 2012 18:45:52 -0500
Message-ID: <201201082345.q08Njqe0002504@svn01.web.mwc.hst.phx2.redhat.com>
--===============3456302768801453300==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Author: smumford
Date: 2012-01-08 18:45:52 -0500 (Sun, 08 Jan 2012)
New Revision: 8279
Added:
epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndIde=
ntity/AuthenticationAuthorizationOverview.xml
epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndIde=
ntity/PasswordEncryption.xml
Log:
JBEPP-1468: Adding new content files
Added: epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAn=
dIdentity/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/5.2/Reference_Guide/en-US/modules/AuthenticationAndId=
entity/AuthenticationAuthorizationOverview.xml (rev=
0)
+++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndId=
entity/AuthenticationAuthorizationOverview.xml 2012-01-08 23:45:52 UTC (rev=
8279)
@@ -0,0 +1,707 @@
+
+
+ %BOOK_ENTITIES;
+ ]>
+
+ Authentication and Authorization intro
+ =
+
+ Authentication Overview
+ =
+
+ Authentication in JBoss Enterprise Portal Platform is based on=
JAAS and by default it is =
a standard J2EE FORM based authentication. =
+
+ =
+
+ JBoss Enterprise Portal Platform supports the following authen=
tication methods:
+
+ =
+
+
+
+ J2EE FORM based authentication
+
+
+ =
+
+
+ The RememberMe authentication method =
(wherein the user checks the Remember my login checkbo=
x on the log in form).
+
+
+ =
+
+
+ SSO server integration (CAS, JOSSO, OpenSSO). Refer to <=
xref linkend=3D"sect-Reference_Guide-SSO_Single_Sign_On" /> for more inform=
ation.
+
+
+ =
+
+
+ SPNEGO authentication with a Kerberos ticket. Refer to <=
xref linkend=3D"sect-Reference_Guide-SSO_Single_Sign_On_-SPNEGO_Simple_and_=
Protected_GSSAPI_Negotiation_Mechanism" /> for more information.
+
+
+ =
+
+
+ Cluster authentication with loadbalancer or with JBoss S=
SO valve. Refer to for more information.
+
+
+
+ =
+
+ Authentication workflow consists of HTTP requests and redirect=
s which include handshakes. Source code related to authentication is partia=
lly included in the WCI module, as the authentication process differs on Servle=
t 2.5 containers and Servlet 3.0 containers.
+
+ =
+
+ First you can see in <JBOSS_HOME>=
/server/<PROFILE>/deploy/gat=
ein.ear/02portal.war/WEB-INF/web.xml that authentication is trig=
gered by accessing a secured URL:
+
+
+
+
+ user authentication
+ /dologin
+ /private/*
+ /g/*
+ /u/*
+
+
+ users
+
+
+ NONE
+
+
+]]>
+
+
+ This means that access to some URLs (such as http://localhost:8080/port=
al/dologin) will directly trigger J2EE authentication in the case t=
hat the 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 recieve an HTTP error; 403 Forbidden, for examp=
le.
+
+ =
+
+ In the next part of the file we can see that authentication is=
FORM based and it starts by redirection to /initiatelogin URL, which is actually mapped to InitiateLoginServlet.
+
+
+
+ FORM
+ gatein-domain
+
+ /initiatelogin
+ /errorlogin
+
+
+]]>
+
+
+ InitiateLoginServlet simply redirects user =
to login page placed in <JBOSS_HOME>/server/<PROFILE>/deploy/gatein.ear/02=
portal.war/login/jsp/login.jsp. =
+
+
+
+
+ =
+
+
+
+
+
+ =
+
+ Changes to the appearance of this login page can be made in th=
is JSP file. You can also change image or CSS placed in <JBOSS_HOME>/server/<PROFILE>/deploy/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. =
+
+
+ This URL is mapped to PortalLoginController servlet, which stores credentials and redirects again to Initiat=
eLoginServlet, which performs a WCI login.
+
+
+ The WCI layer can recognize the current servlet container to d=
etermine if it is the old container with Servlet API 2.5 (JBoss 5, Tomcat 6=
) or the newer container with Servlet API 3.0 (JBoss 6, JBoss 7, Tomcat 7).
+
+ =
+
+ Servlet 3.0
+
+ The newer servlet API supports programmatic authentic=
ation by calling method HttpServletRequest.login(String username, =
String password). This will directly call JAAS authentication wit=
hout needing to perform any redirects.
+
+
+ =
+
+ Servlet 2.5
+
+ The older API does not support programmatic authentic=
ation, so a redirection to a URL which will trigger JAAS authentication (su=
ch as; ) is required. In this case, JAAS au=
thentication is not triggered with a user password but with a WCI ticket wh=
ich is created by InitiateLoginServlet during WCI login =
and saved into WCI TicketService. The purpose of this =
ticket is to avoid using a password during the URL redirection.
+
+
+
+ =
+
+ Login modules
+ =
+
+ JBoss Enterprise Portal Platform uses its own security domain =
(gatein-domain) with a set of predefined=
login modules. Login module configuration for gatein-domain is contained in the deploy/gatein.ear/META-INF/gatein-jboss-b=
eans.xml file.
+
+
+ Below is the default login modules stack:
+
+
+ portal
+ gatein-domain
+
+
+ portal
+ gatein-domain
+
+
+ portal
+ gatein-domain
+
+
+
+
+
+
+ portal
+ gatein-domain
+ ]]>
+
+ New login modules can be added or the stack completely replace=
d with custom modules. =
+
+
+ Some points to consider are:
+
+ =
+
+
+
+ It is possible to log a user in through existing login m=
odules with their credentials (username: root/ password:=
gtn, for example) but also with a WCI ticket (username:=
root/password: wci-ticket-458791). =
The login modules stack supports both of these methods of authentication.
+
+
+ =
+
+
+ Authentication through a WCI ticket is used for FORM bas=
ed authentication in Servlet 2.5 containers (JBoss 5 or Tomcat 6). The majo=
rity of other cases (Servlet 3.0 login, JBoss SSO valve login, login throug=
h Crash=
, BASIC authentication) are using an actual password.
+
+
+ =
+
+
+ Authentication starts with the invocation of the login method on each login module. Once all login methods are invoked, then authentication continues by invoking th=
e commit method on each login module.
+
+
+ Either method (login or commit) can throw LoginException. If this ha=
ppens, the whole authentication process ends unsuccessfully, which in turn,=
invokes the abort method on each login module.
+
+
+ By returning "false" from the login method ensures tha=
t login module is ignored. This is not specific to JBoss Enterprise Portal =
Platform but generic to JAAS. More info about login modules in general can =
be found at .
+
+
+
+ =
+
+ Existing login modules
+ =
+
+ Here is a brief description of existing login modules:
+
+
+ Modules
+
+ WCILoginModule
+
+
+ This login module validates WCI login tic=
kets and then finds the actual username and password of the user from WCI <=
emphasis>TicketService. It saves these details into sha=
redState map. The username is saved under the key javax.=
security.auth.login.name and the password is saved under the key =
javax.security.auth.login.password.
+
+
+ Note
+
+ If you trigger JAAS authentication=
with a literal username and password and not with a WCI ticket credential,=
the WCILoginModule throws a LoginException. However WCILoginModule is declared as "optional", meaning that a login failure in WCILoginMod=
ule is not a critical error to the full login process.
+
+
+
+
+
+ PortalLoginModule
+
+
+ This login module is actually used mainly=
in cluster environments. It uses session replication between cluster nodes=
. After a successful authentication on cluster node1 t=
he commit method adds a flag (with the attribute AUTHENTICATED_CREDENTIALS) to the HTTP session and this fla=
g can then be used to reauthenticate on node2 when it =
executes method login. Refer to for more information.
+
+
+
+
+ SharedStateLoginModule
+
+
+ This login module triggers authentication=
using the Authenticator interface. It takes the usern=
ame and password from the javax.security.auth.login.name=
and javax.security.auth.login.password attributes of th=
e sharedState map.
+
+
+ Then it calls Authenticator.vali=
dateUser(Credential[] credentials), which performs real authentic=
ation of username and password against OrganizationService and portal ident=
ity database. Result of successful authentication is object Ident=
ity, which is saved to sharedState map under key exo.se=
curity.identity. More info in .
+
+
+ SharedStateLoginModule assumes that mention=
ed attributes for username and password are already placed in sharedState m=
ap, which was actually done by WCILoginModule. If attributes are not in sha=
redState map, SharedStateLoginModule is simply ignored (method "login" retu=
rns false).
+
+
+
+
+ JbossLoginModule
+
+
+ Previous login modules (like WCI=
LoginModule and SharedStateLoginModule) are us=
eful for authentication flow with WCI ticket. DefaultLoginModule (superclass of JbossLoginModule) is used for se=
cond case (authentication with real password instead of WCI ticket).
+
+
+ First it checks if Identity object has be=
en already created and saved into sharedState map by SharedStateLoginModule. If not, then it means that WCI tick=
et authentication was not successful and so it tries to login with real pas=
sword of user. It also uses Authentication.validateUser(Credential=
[] credentials) for authentication check.
+
+
+ In method JbossLoginModule.commi=
t, we need to assign our Identity object to IdentityRegi=
stry, which will be used later for authorization. We also need to=
create JAAS principals (UserPrincipal and Role=
sPrincipal) and assign them to our authenticated Subject. This is=
needed for JBoss AS server, so that it can properly recognize name of logg=
ed user and their role on JBoss AS level.
+
+
+
+
+ CustomMembershipLoginModule
+
+
+ Special login module, which is disabled (=
commented) by default. It can be used to add user to some existing group du=
ring successful login of this user. Name of group is configurable and by de=
fault it's /platform/users group. Login module is comm=
ented because in normal environment, users are already in /platfo=
rm/users group. It's useful only for some special setups like re=
ad-only LDAP, where groups of ldap user are taken from ldap tree and so tha=
t users may not be in /platform/users group, which is needed for successful=
authorization.
+
+
+
+
+ =
+
+ SVN location of login modules
+ =
+
+ Some modules are specific for portal, but some are used =
also by eXo JCR and so they are part of eXo core module.
+
+ =
+
+
+
+ PortalLoginModule - is locate=
d in JBoss Enterprise Portal Platform sources in http://anonsvn.jboss.org/repos/gatein/portal/trunk/component/web/secur=
ity/
+
+
+ =
+
+
+ SharedStateLoginModule, JbossLoginModule=
- these are located in eXo core sources in http://anonsvn.jboss.org/repos/exo-jcr/core/trunk/exo.cor=
e.component.security.core/
+
+
+ =
+
+
+ CustomMembershipLoginModule -=
located in JBoss Enterprise Portal Platform sources in module for identity=
integration - http://anonsvn.jboss.org/repos/gate=
in/portal/trunk/component/identity/
+
+
+
+
+
+
+
+ Creating your own login module
+ =
+
+ Before creating your own login module, it is recommended th=
at you study the source code of existing login modules to better understand=
the JAAS authentication process. You need to have good knowledge so that y=
ou can properly decide where your login module should be placed and if you =
need to replace some existing login modules or simply attach your own modul=
e to existing chain.
+
+ =
+
+ We have actually two levels of authentication and overall r=
esult of JAAS authentication should properly handle both these cases:
+
+ =
+
+
+
+ Authentication on application server level
+
+
+ =
+
+
+ Authentication on JBoss Enterprise Portal Platform le=
vel
+
+
+
+ =
+
+ Authentication on application server level
+ =
+
+ Application server needs to properly recognize that user=
is successfuly logged and it has assigned his JAAS roles. Unfortunately th=
is part is not standardized and is specific for each AS. For example in JBo=
ss AS, you need to ensure that JAAS Subject has assigned principal with use=
rname (UserPrincipal) and also RolesPrincipal, which has name "Roles" and i=
t contains list of JAAS roles. This part is actually done in Jbos=
sLoginModule.commit(). In Tomcat, this flow is little different,=
which means Tomcat has it's own TomcatLoginModule.
+
+
+ =
+
+ After successful authentication, user needs to be at lea=
st in JAAS role "users" because this role is declared in web.xml as you saw=
above. JAAS roles are extracted by special algorithm from JBoss Enterprise=
Portal Platform memberships. See below in section with RolesExtractor.
+
+
+ =
+
+ Authentication on JBoss Enterprise Portal Platform l=
evel
+ =
+
+ Login process needs to create special object org.exoplatform.services.security.Identity and regi=
ster this object into JBoss Enterprise Portal Platform component IdentityRegistry. This Identity object should enca=
psulate username of authenticated user, Memberships of this user and also J=
AAS roles. Identity object can be easily created with interface Authenticator as can be seen below.
+
+
+ =
+
+ So have this in mind, if you will extend or replace existin=
g login modules.
+
+
+
+
+ Authenticator and RolesExtractor
+ =
+
+ Authenticator is important component in authentication proc=
ess. Actually interface org.exoplatform.services.security.Authent=
icator looks like this:
+
+
+
+
+
+ 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 createIdentity is used to creat=
e instance of object org.exoplatform.services.security.Identity, which encapsulates all important informations about single user =
like:
+
+ =
+
+
+
+ username
+
+
+ =
+
+
+ set of Memberships (MembershipEntry objects) which us=
er belongs to. Membership is object, which contains in=
formations about membershipType (manager, member, vali=
dator, ... ) and about group (/platform/users, /platfo=
rm/administrators, /partners, /organization/management/executiveBoard, ... =
).
+
+
+ =
+
+
+ set of Strings with JAAS roles of given user. JAAS ro=
les are simple Strings, which are mapped from MembershipEntry objects. Ther=
e is another special component org.exoplatform.services.security.=
RolesExtractor, which is used to map JAAS roles from MembershipE=
ntry objects. RolesExtractor interface looks like this:
+
+
+
+
+ extractRoles(String userId, Set membership=
s);
+}
+ ]]>
+
+
+ Default implementation DefaultRolesExtractorImpl<=
/emphasis> is based on special algorithm, which uses name of role from the =
root of the group (for example for role "/organization/management/something=
" we have JAAS role "organization"). Only exception is group "platform" whe=
re we use 2nd level as name of group. For example from group "/platform/use=
rs" we have JAAS role "users".
+
+ =
+
+ Example: We have user <=
emphasis>root, which has memberships member:/platform/=
users, manager:/platform/administrators, validator:/platform/managers, member:/partners=
, member:/customers/acme, member:=
/organization/management/board. In this case we will have JAAS r=
oles: users, administrators, managers, partners, custome=
rs, organization.
+
+ =
+
+ Default implementation of Authenticator is Organi=
zationAuthenticatorImpl, which is implementation based on OrganizationService. See .
+
+ =
+
+ You can override default implementation of mentioned interf=
aces Authenticator and RolesExtractor if default behaviour is not suitable =
for your needs. Consult documentation of eXo kernel fo=
r more info.
+
+
+
+
+
+
+ Different authentication workflows
+ =
+
+ RememberMe authentication
+ =
+
+ In default login dialog, you can notice that there is "Reme=
mber my login" checkbox, which users can use to persist their login on his =
workstation. Default validity period of RememberMe cookie is 1 day (it is c=
onfigurable), and so user can be logged for whole day before he need to rea=
uthenticate again with his credentials.
+
+ =
+
+ How does it work
+ =
+
+
+
+ User checks the checkbox "Remember my login" on lo=
gin screen of JBoss Enterprise Portal Platform . Then he submit the form.
+
+
+ =
+
+
+ HTTP request like http://localhost:8080/=
portal/login?initialURI=3D/portal/classic&username=3Droot&password=
=3Dgtn&rememberme=3Dtrue is send to server
+
+
+ =
+
+
+ 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.
+
+
+
+
+ =
+
+ Reauthentication
+ =
+
+
+
+ After some time, user wants to reauthenticate. Let=
's assume that his HTTP Session is already expired but his RememberMe cooki=
e is still active.
+
+
+ =
+
+
+ User send HTTP request to some portal page (ie. http://localhost:8080/portal/classic ).
+
+
+ =
+
+
+ There is special HTTP Filter RememberMeFilter configured in web.xml, which checks remember=
me cookie and then it retrieves credentials of user from RemindPasswordToke=
nService. Now filter redirects request to PortalLoginController and authent=
ication process goes in same way as for normal FORM based authentication.
+
+
+
+
+ =
+
+ RemindPasswordTokenService
+ =
+
+ This is special service used during RememberMe authentic=
ation workflow. It's configurable in file deploy/gatein.ear/02por=
tal.war/WEB-INF/conf/common/remindpwd-configuration.xml . For mo=
re info, look at section
+
+ =
+
+ Another thing is that you can encrypt passwords before s=
tore them into JCR. More info is in section .
+
+
+
+ =
+
+ BASIC authentication
+ =
+
+ JBoss Enterprise Portal Platform is using FORM based authen=
tication by default but it's not a problem with switch to different authent=
ication type like BASIC. Only needed thing is to configure it properly in <=
emphasis>deploy/gatein.ear/02portal.war/WEB-INF/web.xml like thi=
s:
+
+
+
+ FORM
+ gatein-domain
+
+ /initiatelogin
+ /errorlogin
+
+
+-->
+
+ BASIC
+ gatein-domain
+
+
+
+ In this case user will see login dialog from browser instea=
d of JBoss Enterprise Portal Platform login.jsp page. JAAS authentication w=
ill be performed with real credentials of user (ie. root/gtn). WCI ticket is not used with BASIC authenticat=
ion.
+
+
+ =
+
+ Cluster login
+ =
+
+ JBoss Enterprise Portal Platform supports automatic login p=
ropagation in cluster environment. Cluster login relies on HTTP session rep=
lication. It's useful for situations like this:
+
+ =
+
+
+
+ You have Apache loadbalancer and two portal nodes node1 and node2
+
+
+ =
+
+
+ User will send request to loadbalancer and he will be=
redirected to node1. All his requests will be then processed on node1 (sti=
cky session).
+
+
+ =
+
+
+ User login on loadbalancer (which is redirected to no=
de1)
+
+
+ =
+
+
+ node1 is killed
+
+
+ =
+
+
+ User will send another HTTP request. He will now be r=
edirected to node2 because node1 is killed. Now user will be automatically =
logged on node2 as well thanks to session replication, because he still has=
same HTTP session, which was replicated from node1 to node2. So end user s=
houldn't recognize any change even if his work is now done on different nod=
e of cluster.
+
+
+
+ =
+
+ This login workflow works thanks to PortalLoginMo=
dule, which is able to save special attribute into HTTP session =
as flag that user is already logged. Then reauthentication on node2 is work=
ing thanks to servlet filter ClusteredSSOFilter, which=
is able to automatically trigger programmatic authentication.
+
+ =
+
+ Note
+
+ ClusteredSSOFilter is using proprietary JBossWeb A=
PI for trigger programmatic authentication and so it's working only on JBos=
s AS. It is not working on other servers like Tomcat or Jetty.
+
+
+ =
+
+ There is also possibility for integration with JBoss cluste=
red SSO valve (See ).
+
+
+ =
+
+ SSO login
+ =
+
+ JBoss Enterprise Portal Platform also supports integration =
with couple of well-known SSO frameworks (CAS, JOSSO, OpenSSO). When user w=
ants login, he is not redirected to portal login form but to SSO server log=
in form. After successful login with SSO server, he gains ticket represente=
d by special cookie (name of cookie differs for each SSO server). Then user=
is redirected back to JBoss Enterprise Portal Platform, where we need to p=
erform agent validation of SSO ticket against SSO server. We still need to =
create Identity object and bind it to IdentityRegistry (this is same as in =
default authentication), which is done thanks to Authenticator component.
+
+ =
+
+ In other words, you need to ensure that users, which are lo=
gged successfuly through SSO, needs to be also in JBoss Enterprise Portal P=
latform identity database because SSO server is used only for authenticatio=
n, but authorization is handled completely by JBoss Enterprise Portal Platf=
orm, which assumes that user exists in portal DB. If users are not in DB, I=
dentity object won't be created and you will have 403 Forbidden errors even=
if you authenticate successfuly. For details about SSO integration, see .
+
+ =
+
+ Same applies for SPNEGO authentication (See ). In this case, you need to ensure that your =
Kerberos users are also created in JBoss Enterprise Portal Platform databas=
e.
+
+
+
+
+
+ Authorization overview
+ =
+
+ In previous section, we learned about JAAS authentication and =
about login modules. So we know that result of authentication are:
+
+ =
+
+
+
+ JAAS Subject with principals for username (UserPrincipal=
) and for JAAS roles (RolesPrincipal).
+
+
+ =
+
+
+ Identity object, which encapsulates username, all member=
ships and all JAAS roles. This Identity object is bound to IdentityRegistry=
component.
+
+
+
+ =
+
+ Authorization in JBoss Enterprise Portal Platform actually hap=
pens on two levels:
+
+ =
+
+ Servlet container authorization
+ =
+
+ First round of authorization is servlet container authoriza=
tion based on secured URL from web.xml. We saw above i=
n web.xml snippet that secured URL are accessible only for users from role =
users:
+
+
+ users
+]]>
+
+ This actually means that our user needs to be in JBoss Ente=
rprise Portal Platform role /platform/users (For detai=
ls see ). In other words, if we successfuly authenticate bu=
t our user is not in group /platform/users, then it means that he is not in=
JAAS role users, which in next turn means that he wil=
l have authorization error 403 Forbidden=
thrown by servlet container.
+
+ =
+
+ You can change the behaviour and possibly add some more auth-constraint elements into web.xml. However this prote=
ction of resources based on web.xml is not standard JBoss Enterprise Portal=
Platform way and it's mentioned here mainly for illustration purposes.
+
+
+ =
+
+ Portal level authorization
+ =
+
+ Second round of authorization is based on component UserACL (See ). We can declare access and=
edit permissions for portals, pages and/or portlets. UserACL is then used =
to check if our user has particular permissions to access or edit specified=
resource. Important object with informations about roles of our user is me=
ntioned Identity object created during JAAS authentica=
tion.
+
+ =
+
+ Authorization on portal level looks like this:
+
+ =
+
+
+
+ user send HTTP request to some URL in portal
+
+
+ =
+
+
+ HTTP request is processed through SetCurrentIdentityFilter, which is declared in de=
ploy/gatein.ear/02portal.war/WEB-INF/web.xml.
+
+
+ =
+
+
+ SetCurrentIdentityFilter reads username of current us=
er from HttpServletRequest.getRemoteUser(). Then it lo=
oks for Identity of this user in IdentityRegistry, where Identity has been =
saved during authentication. Found Identity is then encapsulated into ConversationState object and bound into Threa=
dLocal variable.
+
+
+ =
+
+
+ UserACL is able to obtain Identity of current user fr=
om method UserACL.getIdentity(), which simply calls ConversationState.getCurrent().getIdentity() for find cu=
rrent Identity bound to ThreadLocal. Now UserACL has identity of user and s=
o that it can performs any security checks.
+
+
+
+
+
+
+
Added: epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAn=
dIdentity/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/5.2/Reference_Guide/en-US/modules/AuthenticationAndId=
entity/PasswordEncryption.xml (rev 0)
+++ epp/docs/branches/5.2/Reference_Guide/en-US/modules/AuthenticationAndId=
entity/PasswordEncryption.xml 2012-01-08 23:45:52 UTC (rev 8279)
@@ -0,0 +1,77 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Password Encryption
+
+ Username and passwords stored in clear text
+
+ The Remember Me feature of JBoss Enterpri=
se Portal Platform uses a token mechanism to be able to authenticate return=
ing users without requiring an explicit login. However, to be able to authe=
nticate these users, the token needs to store the username and password in =
clear text in the JCR.
+
+
+
+
+ Administrators have two options available to ameliorate this risk:
+
+
+
+
+ The Remember Me feature can be disabl=
ed by removing the corresponding checkbox in: <JB=
OSS_HOME>/server/<PROFILE>/deploy/gatein.ear/02portal.war/login/jsp/login.jsp and <JBOSS_HOME>/server/<PR=
OFILE>/deploy/gatein.ear/02portal.war/groovy/portal/webui/=
UILoginForm.gtmpl.
+
+
+
+
+
+ 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:
+
+
+ Encrypt Password in JCR
+
+
+ Create a javaclass similar to:
+
+ =
+
+
+
+
+
+ Compile the class and package it into a jar file. =
For this example 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.
+
+ =
+
+
+
+
+
+ Deploy the codec-example.jar =
into your <JBOSS_HOME>/server/<PROFILE>/deploy/gatein.ear/lib/ =
directory.
+
+
+
+
+
+ Start (or restart) your JBoss Enterprise Portal Pl=
atform.
+
+
+ Any passwords written to the JCR will now be encod=
ed and not plain text.
+
+
+
+
+
+ =
+
+
+
+
+
+
\ No newline at end of file
--===============3456302768801453300==--