From do-not-reply at jboss.org Thu Jan 10 20:32:40 2013 Content-Type: multipart/mixed; boundary="===============4805006176090255671==" MIME-Version: 1.0 From: do-not-reply at jboss.org To: gatein-commits at lists.jboss.org Subject: [gatein-commits] gatein SVN: r9043 - epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIdentity. Date: Thu, 10 Jan 2013 20:32:39 -0500 Message-ID: <201301110132.r0B1WdXa006922@svn01.web.mwc.hst.phx2.redhat.com> --===============4805006176090255671== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: rdickens Date: 2013-01-10 20:32:39 -0500 (Thu, 10 Jan 2013) New Revision: 9043 Modified: epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndIde= ntity/AuthenticationAuthorizationOverview.xml Log: Updated content to Confluence wiki version 14 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-01-11 01:32:21 UTC (rev= 9042) +++ epp/docs/branches/6.0/Reference_Guide/en-US/modules/AuthenticationAndId= entity/AuthenticationAuthorizationOverview.xml 2013-01-11 01:32:39 UTC (rev= 9043) @@ -5,6 +5,11 @@ ]> Authentication and Authorization intro + + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D = + NOTE: Content updated to wiki version 4 (11 Jan 2013) + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D +
Authentication Overview @@ -25,54 +30,62 @@ + FIXME: Correct the following link - SSO server integration (CAS, JOSSO, OpenSSO). Refer to <= xref linkend=3D"sect-Reference_Guide-SSO_Single_Sign_On"/> for more informa= tion. + SSO server integration (CAS, JOSSO, OpenSSO). Refer to *= * xref linkend=3D"sect-Reference_Guide-SSO_Single_Sign_On"/ for more inform= ation. + FIXME: Correct the following link - 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. + SPNEGO authentication with a Kerberos ticket. Refer to = ** xref linkend=3D"sect-Reference_Guide-SSO_Single_Sign_On_-SPNEGO_Simple_a= nd_Protected_GSSAPI_Negotiation_Mechanism"/ for more information. + + FIXME: Fix the following link + SAML2 based authentication. Refer to ** xref linkend=3D"= sect-Reference_Guide-SSO_Single_Sign_On_-SAML2"/ for more information. + + + Cluster authentication with load balancer or with JBoss = SSO 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. + 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. - First you can see in JPP_DIST/jboss-as/server/PROFILE/deploy/gatein.ear/0= 2portal.war/WEB-INF/web.xml that authentication is triggered by = accessing a secured URL: + First you can see in JPP_DIST/jboss-as/server/PROFILE/deploy/gatein.ear/p= ortal.war/WEB-INF/web.xml that authentication is triggered by ac= cessing a secured URL _/dologin_: - - user authentication - /dologin - /private/* - /g/* - /u/* - - - users - - - NONE - - + + + user authentication + /dologin + POST + GET + + + 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. + 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 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. - 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. + 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. FORM gatein-domain - /initiatelogin - /errorlogin + /login + /login ]]> - InitiateLoginServlet simply redirects user = to login page placed in JPP_DIST/jboss= -as/server/PROFILE/deploy/gatein.ear/02portal.wa= r/login/jsp/login.jsp. = + LoginServlet redirects the user to the logi= n page placed in JPP_DIST/jboss-as/ser= ver/PROFILE/deploy/gatein.ear/portal.war/login/j= sp/login.jsp. = @@ -98,96 +111,50 @@ - 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 JPP_DIST/jboss-as/server/PROFILE/deploy/gatein.ear/login/skin . + 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 change= images or CSS placed in JPP_DIST/jbos= s-as/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. = + 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. + 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. - - 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 authentic= ation is not triggered with a user password but with a WCI ticket which is = created by InitiateLoginServlet during WCI login and sav= ed into WCI TicketService. The purpose of this ticket = is to avoid using a password during the URL redirection. - -
Login modules -JBoss Portal Platform uses its own security domain (gatein-domain) with a set of predefined login modules. Login m= odule configuration for gatein-domain is contained in = the deploy/gatein.ear/META-INF/gatein-jboss-beans.xml = file. +From the WCI servlet API login, the user is redirected to JAAS authenticat= ion. JBoss Portal Platform uses its own security domain (gatein-domain) with a set of predefined login modules. Log= in module configuration for gatein-domain is contained= in the JPP_DIST/jboss-as/server/PROFILE/deploy/gatein.ear/META-INF/gatein-jboss-beans= .xml file. Below is the default login modules stack: + + QUESTION: Does the reference below "JBossAS7LoginModule" need to be = changed? + - 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. = - + New login modules can be added or the stack completely replaced wit= h custom modules. = + + QUESTION: Should the following reference be to official Red Ha= t documentation instead of Oracle's? - 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). T= he 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 e= nsures that login module is ignored. This is not specific to JBoss Portal P= latform but generic to JAAS. More info about login modules in general can b= e found at . - - - + Authentication starts with the login method of each login module be= ing invoked. After all login methods are invoked, the authentication is con= tinued by invoking the commit method on each login module. Both login and c= ommit methods can throw LoginException. If it happens, then the whole authe= ntication ends unsuccessfully, which in turn invokes the abort method on ea= ch login module. By returning "false" from the login method, you can ensure= that the login module is ignored. This is not specific to JBoss Portal Pla= tform but it is generic to JAAS. Refer to http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/= JAASRefGuide.html here for more information about login modules in = general. +
Existing login modules @@ -196,98 +163,116 @@ Modules - WCILoginModule + SSODelegateLoginModule + FIXME: Fix the link to the relevant CAS section - 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 W= CILoginModule is not a critical error to the full login process. - - + It's useful only if SSO authentication is enabled (disable= d by default. It can be enabled through properties in configuration.propert= ies file and in this case it delegates the work to another real login modul= e for SSO integration. If SSO is disabled, SSODelegateLoginModule is simply= ignored. See ** xref linkend=3D"Central Authentication Service (CAS)#Confi= guration"/ properties details for more details. If SSO is used and SSO auth= entication succeed, the special Identity object will be created and saved i= nto shared state map (Map, which is shared between all login modules), so t= hat this Identity object can be used by JBossAS7LoginModule or other login = modules in the JAAS chain. + - PortalLoginModule + JBossAS7LoginModule - 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 re-authenticate on node2 when it= executes method login. Refer to for more information. - + 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 = JbossAS7LoginModule.commit method, the Identity object is registered to Ide= ntityRegistry, which will be used later for authorization. Also some JAAS p= rincipals (UserPrincipal and RolesPrincipal) and assigned to our authentica= ted Subject. Thi! s is needed for JBoss AS server, so that it can properly recognize the nam= e of the logged user and its roles on an JBoss AS level. + + + + + Some other login modules are not active by default, but can be ad= ded them if you find them useful. + + + - SharedStateLoginModule + CustomMembershipLoginModule - 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. - + 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. + - 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&= quot; returns false). - + Note that the CustomMembershipLoginModule can't be the firs= t login module in the LoginModule chain because it assumes that the Identit= y object is already available in shared state. So there are two possible ca= ses. For an non-SSO case, you may need to chain this LM with other login mo= dules, which can be used to establish Identity and add it into shared state= . Those LM can be InitSharedStateLoginModule and SharedStateLoginModule. Fo= r an SSO case, you can add CustomMembershipLoginModule between SSODelegateL= oginModule and JBossAS7LoginModule. + - 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. - - + InitSharedStateLoginModule + + + It can read credentials from JAAS callback and add th= em into shared state. It's intended to be used in JAAS chain before SharedS= tateLoginModule + + - 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, by defau= lt it is /platform/users group. - - - This login module is commented because in = normal environment, users are already in /platform/users group. It is useful only for some special setups like read-only LDAP, wh= ere groups of ldap user are taken from ldap tree and so that users may not = be in /platform/users group, which is needed for succe= ssful authorization. - - + 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. + + -
- 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 Portal Platform sources in http://a= nonsvn.jboss.org/repos/gatein/portal/trunk/component/web/security/ - - - - - 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 Portal Platform sources in module for identity integratio= n - http://anonsvn.jboss.org/repos/gatein/portal/t= runk/component/identity/ - - - -
+ = + + Configuration example with CustomMembershipLoginModule and disabl= ed SSO: + + + + + + + + + + + + + + + + + + + ]]> + + + + And a configuration example with enabled SSO: + + = + + + + + + + + + + + + + + + + + ]]> + + = + =
-
+ = +
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. + 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 the existing chain. - We have actually two levels of authentication and overall r= esult of JAAS authentication should properly handle both these cases: + There are two levels of authentication and the overall resu= lt of JAAS authentication should properly handle both these cases: @@ -304,27 +289,26 @@ Authentication on application server level - Application server needs to properly recognize that user= is successfully logged and it has assigned his JAAS roles. Unfortunately t= his part is not standardized and is specific for each AS. For example in JB= oss AS, you need to ensure that JAAS Subject has assigned principal with us= ername (UserPrincipal) and also RolesPrincipal, which has name "Roles&= quot; and it contains list of JAAS roles. This part is actually done in JbossLoginModule.commit(). In Tomcat, this flow is little differe= nt, which means Tomcat has it is own TomcatLoginModule. - + 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 AS, = you need to ensure that JAAS Subject has assigned principal with username (= UserPrincipal) and also RolesPrincipal, which has name "Roles" an= d it contains list of JAAS roles. This part is actually done in Jboss= LoginModule.commit(). In Tomcat, this flow is little different, whic= h means Tomcat has it is 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 = Portal Platform memberships. See below in section with RolesExtractor. - + After successful authentication, user needs to be at least in JAAS= role "users" because this role is declared in web.xml<= /filename> as you saw above. JAAS roles are extracted by special algorithm = from JBoss Portal Platform memberships. See below in section with RolesExtr= actor. + Authentication on JBoss Portal Platform level - Login process needs to create special object or= g.exoplatform.services.security.Identity and register this object= into JBoss Portal Platform component IdentityRegistry. = This Identity object should encapsulate username of authenticated user, Mem= berships of this user and also JAAS roles. Identity object can be easily cr= eated with interface Authenticator as can be seen below. - + The login process needs to create a special object org.= exoplatform.services.security.Identity and register this object i= nto JBoss Portal Platform component IdentityRegistry. Th= e Identity object should encapsulate the username of the authenticated user= , memberships of this user and JAAS roles. The Identity object can be easil= y created with interface Authenticator as shown 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: - + Authenticator is an important component in the authentication pro= cess. The interface org.exoplatform.services.security.Authenticat= or looks like this: + 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 information about single user l= ike: + Method createIdentity is used to creat= e instance of object org.exoplatform.services.security.Identity, which encapsulates all important information about a single user: @@ -367,10 +351,13 @@ - 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: + 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: + - 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/some= thing" we have JAAS role "organization"). Only exception is = group "platform" where we use second level as name of group. For = example from group "/platform/users" we have JAAS role "user= s". + Default implementation DefaultRolesExtractorImpl<= /emphasis> is based on a special algorithm, which uses the name of the role= from the root of the group (for example for role "/organization/manag= ement/something" we have JAAS role "organization"). The only= exception is the "platform" group where we use second level as t= he name of the group. For example from group "/platform/users" 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. @@ -396,6 +383,7 @@ Default implementation of Authenticator is Organi= zationAuthenticatorImpl, which is implementation based on OrganizationService. See . + FIXME: Change the following reference to eXo kernel You can override default implementation of mentioned interf= aces Authenticator and RolesExtractor if default behavior is not suitable f= or your needs. Consult documentation of eXo kernel for= more info. @@ -433,17 +421,17 @@ - After some time, user wants to re-authenticate. Le= t's assume that his HTTP Session is already expired but his RememberMe= cookie is still active. + After some time, the user wants to re-authenticate= . It is assumed that his HTTP Session is already expired but his RememberM= e cookie is still active. - User send HTTP request to some portal page (). + The user sends the HTTP request to some portal pag= es (for example, ). - 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. + There is a special HTTP Filter RememberMeFilter configured in web.xml, which checks the Re= memberMe cookie and then it retrieves credentials of user from RemindPasswo= rdTokenService. Now filter redirects request to PortalLoginController and a= uthentication process goes in same way as for normal FORM based authenticat= ion. @@ -451,101 +439,17 @@
RemindPasswordTokenService - This is special service used during RememberMe authentic= ation workflow. It is configurable in file deploy/gatein.ear/02po= rtal.war/WEB-INF/conf/common/remindpwd-configuration.xml . For m= ore info, look at section + This is a special service used during the RememberMe aut= hentication workflow. It is configurable in the file JPP_DIST/jboss-as/server/PROFILE/= deploy/gatein.ear/02portal.war/WEB-INF/conf/common/remindpwd-configuration.= xml . For more info, look at section - Another thing is that you can encrypt passwords before s= tore them into JCR. More info is in section . + You can encrypt passwords before storing them in JCR. Mo= re info is in section .
-
- BASIC authentication - -JBoss Portal Platform is using FORM based authentication by default but it= is not a problem with switch to different authentication type like BASIC. = Only needed thing is to configure it properly in deploy/gatein.ea= r/02portal.war/WEB-INF/web.xml like this: - - - - FORM - gatein-domain - - /initiatelogin - /errorlogin - - ---> - - BASIC - gatein-domain - - - - In this case user will see login dialog from browser instea= d of JBoss Portal Platform login.jsp page. JAAS authentication will be perf= ormed with real credentials of user (root/gt= n). WCI ticket is not used with BASIC authentication. - -
-
- Cluster login - -JBoss Portal Platform supports automatic login propagation in cluster envi= ronment. Cluster login relies on HTTP session replication. 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 pr= ocessed on node1 (sticky session). - - - - - User login on loadbalancer (which is redirected to node1) - - - - - 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 s= ession, which was replicated from node1 to n= ode2. So end user shouldn't recognize any change even if hi= s work is now done on different node 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 nod= e2 is working thanks to servlet filter ClusteredSSOFil= ter, which is able to automatically trigger programmatic authent= ication. - - - Note - - ClusteredSSOFilter is using pro= prietary JBossWeb API for trigger programmatic authentication and so it is = working only on JBoss 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 Portal Platform also supports integration with couple of well-known = SSO frameworks (CAS, JOSSO, OpenSSO). When user wants login, he is not redi= rected to portal login form but to SSO server login form. After successful = login with SSO server, he gains ticket represented by special cookie (name = of cookie differs for each SSO server). Then user is redirected back to JBo= ss Portal Platform, where we need to perform 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 don= e thanks to Authenticator component. - - - In other words, you need to ensure that users, which are lo= gged successfully through SSO, needs to be also in JBoss Portal Platform id= entity database because SSO server is used only for authentication, but aut= horization is handled completely by JBoss Portal Platform, which assumes th= at user exists in portal DB. If users are not in DB, Identity object won&ap= os;t be created and you will have 403 Forbidden errors even if you authenti= cate successfully. 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 Portal Platform = -
-
-
+
Authorization overview - In previous section, we learned about JAAS authentication and = about login modules. So we know that result of authentication are: + In the previous section, you learned about JAAS authentication= and about login modules. So you know the result of authentication, includi= ng: @@ -571,17 +475,18 @@ users ]]> + FIXME: correct the link to 'Login modules' - This actually means that our user needs to be in JBoss Port= al Platform role /platform/users (For details see ). In other words, if we successfully authenticate but our user = is not in group /platform/users, then it means that he= is not in JAAS role users, which in next turn means t= hat he will have authorization error 403 Forbidden<= /emphasis> thrown by servlet container. + This actually means that our user needs to be in JBoss Port= al Platform role /platform/users (For details see ). In other words, if we successfully authenticate but our user = is not in group /platform/users, then it means that he= is not in JAAS role users, which in turn means that t= hey will have authorization error 403 Forbidden thrown by servlet container. For example in LDAP setup, your users= may not be in /platform/users by default, but you can use CustomMembership= LoginModule to fix this problem. For details see ** Login modules**. - You can change the behavior and possibly add some more auth-constraint elements into web.xml= . However this protection of resources based on web.xml is not standard JBo= ss Portal Platform way and it is mentioned here mainly for illustration pur= poses. + You can change the behavior and possibly add some more auth-constraint elements into web.xml= . However this protection of resources based on web.xml is not standard JBo= ss Portal Platform method and is mentioned here mainly for illustration pur= poses.
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 t= o check if our user has particular permissions to access or edit specified = resource. Important object with information about roles of our user is ment= ioned Identity object created during JAAS authenticati= on. + The second round of authorization is based on the component= UserACL (See ). You can declare ac= cess and edit permissions for portals, pages and/or portlets. UserACL is th= en used to check if our user has particular permissions to access or edit s= pecified resources. An important object containing information about the ro= les of our user is the Identity object created during = JAAS authentication. Authorization on portal level looks like this: @@ -589,25 +494,26 @@ - user send HTTP request to some URL in portal + The user sends a HTTP request to some URLs in portal; - HTTP request is processed through SetCurrent= IdentityFilter, which is declared in deploy/gatein.ear/= 02portal.war/WEB-INF/web.xml. + The HTTP request is processed through SetCur= rentIdentityFilter, which is declared in J= PP_DIST/jboss-as/server/PROFILE/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. + 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. The Identity found is then encapsulated into a= ConversationState object and bound into= the ThreadLocal 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. + UserACL is able to obtain Identity of current user fr= om method UserACL.getIdentity(), which simply calls ConversationState.getCurrent().getIdentity() to find the= current Identity bound to ThreadLocal. Now the UserACL has the identity of= the user and can perform any security checks.
+
--===============4805006176090255671==--