From portal-commits at lists.jboss.org Tue Apr 17 09:32:26 2007 Content-Type: multipart/mixed; boundary="===============5346874970942006880==" MIME-Version: 1.0 From: portal-commits at lists.jboss.org To: portal-commits at lists.jboss.org Subject: [portal-commits] JBoss Portal SVN: r6986 - docs/trunk/referenceGuide/en/modules. Date: Tue, 17 Apr 2007 09:32:25 -0400 Message-ID: --===============5346874970942006880== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: julien(a)jboss.com Date: 2007-04-17 09:32:25 -0400 (Tue, 17 Apr 2007) New Revision: 6986 Modified: docs/trunk/referenceGuide/en/modules/authentication.xml docs/trunk/referenceGuide/en/modules/identity.xml docs/trunk/referenceGuide/en/modules/ldap.xml docs/trunk/referenceGuide/en/modules/sso.xml Log: JBPORTAL-1295 : before tagging docs for beta1 check the identity part Modified: docs/trunk/referenceGuide/en/modules/authentication.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 --- docs/trunk/referenceGuide/en/modules/authentication.xml 2007-04-17 13:2= 0:32 UTC (rev 6985) +++ docs/trunk/referenceGuide/en/modules/authentication.xml 2007-04-17 13:3= 2:25 UTC (rev 6986) @@ -7,12 +7,12 @@ Authentication and Authorization - This chapter describes authentication mechanisms in JBoss Portal<= /para> + This chapter describes the authentication mechanisms in JBoss Por= tal Authentication in JBoss Portal JBoss Portal is heavily standard based so it leverages Java Authentication and Authorization Service (JAAS) - in JBoss Application Server. Because of this it can be very flexi= bly configured, and other - authentication solutions can be plugged in really easily. + in JBoss Application Server. Because of this it can be configured= in a very flexible manner and other + authentication solutions can be plugged in easily. To better understand authentication mechanisms in JBoss Portal pl= ease refer to Security chapter. To learn more about JAAS look for proper documentation on @@ -22,25 +22,25 @@ Configuration - You can configure JAAS authentication stack in jb= oss-portal.sar/conf/login-config.xml. - What is very important to remember is that authorisation in porta= l starts in JAAS level - + You can configure the JAAS authentication stack in jboss-portal.sar/conf/login-config.xml. + It is important to remember that authorisation in portal starts a= t the JAAS level - configured LoginModules apply proper Principal objects representing - roles to authenticated user. Like you can see in jbo= ss-portal.sar/portal-server.war/WEB-INF/web.xml portal - servlet is secured with specified role ("Authenticated<= /emphasis>"). In default portal configuration - this role is dynamically added by IdentityLoginModule. If you reconfigure default JAAS authentication - chain with other LoginModule implementati= ons, please remember you must fit in this - security constraints to be able to access portal. For example if = you place only one LoginModule + the roles of authenticated user. As you can see in j= boss-portal.sar/portal-server.war/WEB-INF/web.xml portal + servlet is secured with specified role ("Authenticated<= /emphasis>"). In the default portal configuration + this role is dynamically added by IdentityLoginModule. If you reconfigure the default JAAS authentication + chain with other LoginModule implementati= ons, you should remember that you must deal with that + security constraints in order to be able to access portal. For ex= ample if you place only one LoginModule that will authenticate users against LDAP server you may consi= der adding all users in your LDAP tree to such role. JAAS Login Modules - JBoss Portal comes with few implementations of JAAS = LoginModule interface + JBoss Portal comes with a few implementations of JAAS LoginModule interface org.jboss.portal.identity.auth.IdentityLoginModule - This is standard portal LoginModule implementation, that us= e portal identity modules to search for users and roles. By default it's th= e only - configured LoginModule in the portal authentication stack. Its be= haviour can be altered with following options: + This is the standard portal LoginModule implementation that= uses portal identity modules in order to search users and roles. + By default it is the only configured LoginModule in the portal au= thentication stack. Its behaviour can be altered with the following options: userModuleJNDIName - = JNDI name of portal UserModule. @@ -120,13 +120,12 @@ org.jboss.portal.identity.auth.SynchronizingLdapLoginModul= e - Use can use this module instead of IdentityLoginModule to bind= to LDAP. + This module can be used instead of the IdentityLoginModule to = bind to LDAP. org.jboss.portal.identity.auth.SynchronizingLDAPLogi= nModule class is a wrapper around - LdapLoginModule from JBossSX. - It simply extends it so - all configuration that can be applied to LdapExtLoginM= odule also can be applied here. For user that - was authenticated successfully it will try to call identity mo= dules from portal, check if such user - is present, and if not it will try to create it. Then for all = roles assigned to this authenticated principal it will + LdapLoginModule from JBossSX. + It extends it so all configuration that can be applied to LdapExtLoginModule remains valid here. For a user that + was authenticated successfully it will try to call the identit= y modules from portal, then check if such user + exists or not, and if does not exist it will try to create it.= Then for all roles assigned to this authenticated principal it will try to check and create them using identity modules. This beha= viour can be altered using following options: @@ -171,32 +170,30 @@ made around LdapExtLoginModule from JBossSX. Sample configuration can look like this: - true - true - Authenticated - User - java:/portal/UserMo= dule - java:/portal/RoleMo= dule - java:/portal/= MembershipModule - java:/portal= /UserProfileModule - com.sun.jn= di.ldap.LdapCtxFactory - ldap://exampl= e.com:10389/ - si= mple - cn=3DDirectory Manager - secret - ou=3DPeople,dc=3Dexample,dc= =3Dcom - (uid=3D{0}) - ou=3DRoles,dc=3Dexample,dc= =3Dcom - (member=3D{1}) - cn - -1 - 10000 - SUBTREE_SCOPE - false - - ]]> + + true + true + Authenticated + User + java:/portal/UserModule + java:/portal/RoleModule + java:/portal/Membershi= pModule + java:/portal/UserProf= ileModule + com.sun.jndi.ldap.L= dapCtxFactory + ldap://example.com:103= 89/ + simple + cn=3DDirectory Manager + secret + ou=3DPeople,dc=3Dexample,dc=3Dcom + (uid=3D{0}) + ou=3DRoles,dc=3Dexample,dc=3Dcom + (member=3D{1}) + cn + -1 + 10000 + SUBTREE_SCOPE + false +]]> @@ -205,8 +202,8 @@ This module is designed to provide synchronization support for= any other LoginModule placed in the authentication stack. It leverages the fact that in JAAS authentication process occu= rs in two phases. In first phase when login() method is invoked it always returns "true". Because of this behaviour = SynchronizingLoginModule should be always used with - "optional" flag.. - Morover it should be placed after module we want to leverage a= s a source for synchronization and this module should have "required" flag = set. + "optional" flag. + More over it should be placed after the module we want to leve= rage as a source for synchronization and that module should have "required"= flag set. During the second phase when commit() method is invoked it get= s user Subject and its Principals and tries to synchronize them into storage configured for port= al identity modules. For this purposes such options are supported: Modified: docs/trunk/referenceGuide/en/modules/identity.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 --- docs/trunk/referenceGuide/en/modules/identity.xml 2007-04-17 13:20:32 U= TC (rev 6985) +++ docs/trunk/referenceGuide/en/modules/identity.xml 2007-04-17 13:32:25 U= TC (rev 6986) @@ -256,9 +256,9 @@ = - Ways to access identity modules + How to obtain identity modules services ? - The best way to access identity modules is by using JNDI: + The advocated way to get a reference to the identity modules i= s by using JNDI: import org.jboss.portal.identity.UserModule; @@ -273,7 +273,7 @@ (MembershipModule)new InitialContext().lookup("java:portal/MembershipModul= e"); (UserProfileModule)new InitialContext().lookup("java:portal/UserProfileMod= ule"); - Another way to do this is, if you are fimiliar with JBoss Mikr= okernel architecture is to + Another way to do this is, if you are fimiliar with JBoss Micr= okernel architecture is to get the IdentityServiceController mbean. You may want to inject it into your services like this: @@ -371,30 +371,29 @@ Identity configuration - At the beginning to understand identity configuration you need= to understand how it is designed to work in portal. + In order to understand identity configuration you need to unde= rstand its architecture. Different identity services like UserModule, RoleModule and etc a= re just plain java classes that are instantiated and exposed - by portal. So *example* UserModule service could be plain java b= ean object that will be: + by the portal. So an *example* of UserModule service could be a p= lain java bean object that would be: Instantiated usin= g reflection Initialized/Started by invoking some methods Registered/Exposed using JNDI and/or mbeans (JBoss Microkernel) services, so - other citizens of the portal can use it + other services of the portal can use it Managed in the ma= tter of lifecycle - so it'll be stopped and unregistered during portal shutdown - As you see from this standpoint configuration just specifies whic= h java class and how should be used by portal as a service. - We use JBoss Microcontainer to manage state of those compon= ents so if you are interested in implementation of - custom ones - look on the methods that are leveraged by this fram= ework. + As you see from this point of view, configuration just specifies = what java class will be used and how it should be used by portal as a servi= ce. + We use JBoss Microcontainer internally to manage the sub sy= stem made of those components so if you are interested in implementing + custom services - look on the methods that are used by this frame= work. - In JBoss Portal we provide very flexible configuration. It's very= easy to rearrange and customize services, - provide and plug in own implementations, extend current ones or e= xtend identity model with own solutions using - provided configuration service. + In JBoss Portal we provide a very flexible configuration. It is v= ery easy to rearrange and customize services, + provide alternative implementations, extend the existing ones or = provide a custom identity model. - To have the complete picture of the configuration of identity = services lets start from it's root - component. Whole configuration and setup of identity components i= s made by - IdentityServiceController. It = brings to life and registers all other components - like UserModule, RoleModule, MembershipModule and UserProfileModu= le. + To grasp the full picture of the configuration of identity ser= vices let's start from its root + component. Whole configuration and setup of identity components i= s done by the + IdentityServiceController serv= ice. It brings to life and registers all other services + such as UserModule, RoleModule, MembershipModule and UserProfileM= odule. IdentityServiceController is d= efined in jboss-portal.sar/META-INF/jboss-service.xml @@ -414,7 +413,7 @@ conf/identity/standardidentity-co= nfig.xml ]]> - We can specify few options here: + We can specify a few options here: @@ -424,17 +423,17 @@ - ConfigFile - defines = location of main identity services configuration + ConfigFile - defines = the location of the main identity services configuration file. It describes and configures all the components lik= e UserModule, RoleModule... that need to be instantiated - DefaultConfigFile - d= efines location of configuration file containing - default values. For each component defined in ConfigFile IdentityServiceController - will look into this location to grab set of default opti= ons. This simply makes the main configuration file - simpler and shorter while still enabling more powerful c= ustomization. + DefaultConfigFile - d= efines the location of the configuration file containing + the default values. For each component defined in ConfigFile, the IdentityServiceController + will obtain a set of default options from this file. Tha= t helps to keep the main main configuration file + simple, short and easy to read. Potentially it provides = more powerful customizations. @@ -471,7 +470,7 @@ This section defines datasource components. They will be= processed and instantiated before components in Module section, so they wil= l be ready to serve them. This section isn't used with Database configuration as i= n JBoss Portal services exposing Hibernate - are defined separately. It's used by LDAP configuration and we= 'll use it as an example + are defined separately. It is used by LDAP configuration and w= e will use it as an example LDAP @@ -501,8 +500,8 @@ ]]> If you look into JBoss Portal configuration files you wi= ll find that and ]]> are specified in DefaultConfigFile and not in ConfigFile. - So this is how it works. Those two will be picked up from defa= ult configuration. The same rule takes place - for options - additional will be picked up from default config= uration. What is linking configuration in those two files + So here is how it works: those two will be picked up from defa= ult configuration. The same rule is effective + for the options - additional options will be picked up from de= fault configuration. What is linking configuration in those two files is the ]]> t= ag. @@ -534,22 +533,22 @@ implementation - d= efines the scope under which - configuration for different implementations of module= s types are kept. - It enables to keep configurations of different implem= entations of same module types in one configuration file - with default options. + the configuration for different implementations of mo= dules types resides. + It enables to define the default options of the confi= guration of the different implementations of + same module types in one configuration file. type - must be uni= que name across all modules defined in the main configuration file. This is important as module will = be stored with such name within IdentityContext - registry on runtime. Standard names are used (User, R= ole, Membership, UserProfile). Together with + registry at runtime. Standard names are used (User, R= ole, Membership, UserProfile). Together with implementation wil= l create unique pair within file with default configuration values. - service-name - wil= l be used for registration as an MBean. + service-name - wil= l be used for the name when registered as an MBean. @@ -574,16 +573,16 @@ DB ]]> - As you see we specify only type and implementation - all th= e other values (service-name, class and set of options) - will be taken from default configuration. But remember that= still you can overwrite any of those values in the - main config simply by specifying them. + As you can see we specify only the type and the implementat= ion - all the other values (service-name, class and set of options) + are read from default configuration. But remember that you = can still overwrite any of those values in the + main config simply by overriding them. = Options - This section provides common options that are accessible= by identity modules. We put here options - that may need to be shared. They are grouped, and can have man= y values: + This section provides common options that are accessible= by identity modules. We set options + here that may need to be shared. They are grouped, and can hav= e many values: @@ -641,9 +640,9 @@ none ]]> - In this section we use the same inheritance mechanism. W= hen option is not set, it's value will be taken - from the default config file. But this also means that you nee= d to overwrite some values that - are specific for your LDAP architecture. All the options will = be described along with module implementations + In this section we use the same inheritance mechanism. W= hen an option is not set, its value will be read + from the default config file. But this also means that you may= need to overwrite some values that + are specific to your LDAP architecture. All the options will b= e described along with module implementations that use them. @@ -730,12 +729,13 @@ ]]> - Configuration file contains properties definition that can be ret= rieved using PropertyInfo interface. - Every property that will be used in portal need to be registered = here. - Some information provided for property have big influence o= n the behaviour of UserProfileModule. For example - access-mode can made property read-only, and= value provided in type will be checked + Configuration file contains properties definition that can be ret= rieved using the PropertyInfo interface. + Each property used in portal has to be defined here. + Some information provided here can have a large impact on t= he behaviour of the UserProfileModule. For instance + access-mode can be made read-only and the va= lue provided in type will be checked during setProperty()/getProperty() operation= s. On the other hand tags like usage, - description or display-name have mostly informational meaning at the moment + description or display-name have mostly informational meaning at the moment and + are used by the management tools at runtime. name - property name. Th= is value will be used to refer to the property in UserProfileModu= le @@ -783,7 +783,7 @@ JBoss portal comes with a set of database related identity = modules implementations done using Hibernate - those are configured by default. Those are not very configurable in identity-config.xml file. Th= e reason is that to keep backwards compatibility of database schema with pr= evious - portal version, we reused most of hibernate implementation. If= you want to trigger hibernate mappings you should look into files in + portal version, we reused most of hibernate implementation. If= you want to tweak the hibernate mappings you should look into files in jboss-portal.sar/conf/hibernate. Also those modules rely on hibernate SessionFactory= components that are created in SessionFactoryBinder mbe= ans defined in jboss-portal.sar/META-INF/jboss-service.xml Classes implementing identity modules: @@ -816,8 +816,9 @@ Delegating UserProfile module Delegating UserProfileModule implementation has very specif= ic role. When we use storage mechanism like LDAP we may not be able to map = all - user properties into LDAP attributes because of schema limitation= s. To solve this problem we use database to store such not mapped propertie= s. - Delegating user profile module will recognize if property is mapp= ed as ldap or da= tabase + user properties into LDAP attributes because of schema limitation= s. To solve this problem we still can use the database to store user proper= ties + that do not exist in the LDAP schema. + Delegating user profile module will recognize if a property is ma= pped as ldap or = database and delegate setProperty()/getProperty() met= hod invocation to proper module implementation. This is implemented in org.jboss.portal.identity.DelegatingUserP= rofileModuleImpl. If property is mapped either as ldap and database the ldap mapping = will @@ -825,31 +826,30 @@ - - UserProfile - DELEGATING + + + UserProfile + DELEGATING = - - portal:service=3DModule,type=3DUserProfile - org.jboss.portal.identity.DelegatingUserProfileModuleImpl<= /class> - - - - - - - - ]]> + + portal:service=3DModule,type=3DUserProfile + org.jboss.portal.identity.DelegatingUserProfileModuleImpl + + + + + + +]]> Module options are: @@ -868,27 +868,27 @@ Database UserProfile module implementation - Because of behaviour described in previous section database= UserProfileModule needs some special capabilities. If user is present in - LDAP server but property we want to store isn't mapped as LDAP at= tribute such property need to be stored in database. But to store - the property user need to be synchronized from ldap into database= first + Because of the behaviour described in the previous section,= database UserProfileModule requires some special features. If a user is pr= esent in + LDAP server but a writable property isn't mapped as an LDAP attri= bute, such property requires to be stored in the database. In order to achi= eve + such result the user need to be synchronized from ldap into the d= atabase first. Class org.jboss.portal.identity.db.HibernateUserP= rofileModuleImpl has additional synchronization features. Here are the options: - synchronizeNonExistingUsers - when set to "true" if user on which we want to perform operation does= n't exist it will - create it in database. Default is "true". + synchronizeNonExistingUsers - when set to "true" if the user subject to the operation does not exis= t, then it will + created it in database. By default it is "true". acceptOtherImplementations - if set to "true" module will accept user objects other than org.jboss.portal.identity.db.HibernateUserImpl. This is needed to enable cooperation with UserModule implementati= ons other - than org.jboss.portal.identity.db.HibernateUserMo= duleImpl. Default is "true". + than org.jboss.portal.identity.db.HibernateUserMo= duleImpl. The default value is set "true". defaultSynchronizePassword - if this option is set, the value will be used as a password for synchr= onized user. randomSynchronizePassword - if this option is set to "true" synchronized user will have random gene= rated password. - This is mostly used for the security reasons. Default is "f= alse". + This is mostly used for the security reasons. Default value= is "false". sessionFactoryJNDIName -= JNDI name under which this user will be registered. @@ -899,7 +899,6 @@ - = Modified: docs/trunk/referenceGuide/en/modules/ldap.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 --- docs/trunk/referenceGuide/en/modules/ldap.xml 2007-04-17 13:20:32 UTC (= rev 6985) +++ docs/trunk/referenceGuide/en/modules/ldap.xml 2007-04-17 13:32:25 UTC (= rev 6986) @@ -8,12 +8,12 @@ LDAP This chapter describes how to setup LDAP support in JBoss Portal<= /para> - To be able to fully understand this chapter you should study JBoss Portal Identity management and + To be able to fully understand this chapter you should also read = JBoss Portal Identity management and Authentication chapters before<= /note> How to enable LDAP usage in JBoss Portal - We'll describe here the simple steps that you'll need to perfo= rm to enable LDAP support in JBoss Portal. - For additional information you need to study more about configura= tion of identity and specific implementations of identity modules + We'll describe here the simple steps that you will need to per= form to enable LDAP support in JBoss Portal. + For additional information you need to read more about configurat= ion of identity and specific implementations of identity modules There are two ways to achieve this: @@ -52,7 +52,7 @@ - After doing one of above changes you need to edit configuration f= ile that you choose to + After doing one of the above changes you need to edit configurati= on file that you choose to use (identity-config.xml or ldap_identity-config.xml) and configu= re LDAP connection options in section: This is the base implementation of LDAP UserMo= dule. It supports user creation, but will retreive users and cre= ate them in strictly specified place in LDAP tree. To enable it in your configuration you should have: - - - - User - LDAP - - - ]]> - + + + User + LDAP + +]]> org.jboss.portal.identity.ldap.LDAPUserModuleImpl config= uration option-groups options: @@ -252,42 +249,40 @@ Example configuration: - common - - - - - - userCreateAttibutes - - - - - - ]]> - + + common + + + + + + userCreateAttibutes + + + + +]]> = @@ -296,16 +291,14 @@ Aim of this implementation is to give more flexibility f= or users retreival. You can specify LDAP filter that will be used for searches. This module doesn't support us= er creation and removal To enable it in your configuration you should have: - - - - User - LDAP - org.jboss.portal.identity.ldap.LDAPExtUserModu= leImpl - - - ]]> + + + User + LDAP + org.jboss.portal.identity.ldap.LDAPExtUserModuleImpl + + org.jboss.portal.identity.ldap.LDAPExtUserModuleImpl con= figuration option-groups options: @@ -392,15 +385,13 @@ This is the base implementation of LDAP RoleMo= dule. It supports user creation, but will retreive roles and cre= ate them in strictly specified place in LDAP tree. To enable it in your configuration you should have: - - - - Role - LDAP - - - ]]> + + + Role + LDAP + +]]> org.jboss.portal.identity.ldap.LDAPRoleModuleImpl config= uration option-groups options: @@ -431,16 +422,14 @@ that will be used for searches. This module doesn't support ro= le creation and removal This module doesn't support role creation and removal To enable it in your configuration you should have: - - - - Role - LDAP - org.jboss.portal.identity.ldap.LDAPExtRoleModu= leImpl - - - ]]> + + + Role + LDAP + org.jboss.portal.identity.ldap.LDAPExtRoleModuleImpl + +]]> org.jboss.portal.identity.ldap.LDAPExtRoleModuleImpl con= figuration option-groups options: @@ -544,15 +533,13 @@ LDAPStaticGroupMembershipModuleImpl This module support tree shape where role entries keep i= nformation about users that are their members. To enable it in your configuration you should have: - - - - Membership - LDAP - - - ]]> + + + Membership + LDAP + +]]> org.jboss.portal.identity.ldap.LDAPStaticGroupMembership= ModuleImpl configuration option-groups options: @@ -577,16 +564,14 @@ LDAPStaticRoleMembershipModuleImpl This module support tree shape where user entries keep i= nformation about roles that they belong to. To enable it in your configuration you should have: - - - - Membership - LDAP - org.jboss.portal.identity.ldap.LDAPStaticRoleM= embershipModuleImpl - - - ]]> + + + Membership + LDAP + org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipModuleImp= l + +]]> org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipM= oduleImpl configuration option-groups options: @@ -614,34 +599,32 @@ LDAPUserProfileModuleImpl This is standard implementation that enables to retreive= user properties from atributes in LDAP entries. To enable it in your configuration you should have: - - - UserProfile - DELEGATING - - - - - - DBDelegateUserProfile - DB - - - - - - LDAPDelegateUserProfile - LDAP - - - ]]> + + UserProfile + DELEGATING + + + + + + DBDelegateUserProfile + DB + + + + + + LDAPDelegateUserProfile + LDAP + +]]> Using such configuration you will have LDAP Membershi= pModule along with DB MembershipModule and Delegating MembershipModule. Ple= ase read Identity chapter to see why this is important. @@ -698,8 +681,7 @@ Example LDIF - - - +member: uid=3Dadmin,ou=3DPeople,dc=3Dexample,dc=3Dcom]]> Example identity configuration - - - - - User - LDAP - - - - Role - LDAP - - - - Membership - LDAP - - - - UserProfile - DELEGATING - - - - - - DBDelegateUserProfile - DB - - - - - - LDAPDelegateUserProfile - LDAP - - - - - - - common + + + + User + LDAP + + + + Role + LDAP + + + + Membership + LDAP + + + + UserProfile + DELEGATING + + + + + DBDelegateUserProfile + DB + - - - userCreateAttibutes - - - - - - - roleCreateAttibutes - - - - - - + + + + LDAPDelegateUserProfile + LDAP + + + = - ]]> - + + + common + + + + + userCreateAttibutes + + + + + + + roleCreateAttibutes + + + + + + +]]> = @@ -877,8 +853,7 @@ Example LDIF - - - +description: the JBoss Portal admin group]]> Example identity configuration - - - - - User - LDAP - - - - Role - LDAP - - - - Membership - LDAP - org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipMod= uleImpl - - - - UserProfile - DELEGATING - - - - - - DBDelegateUserProfile - DB - - - - - - LDAPDelegateUserProfile - LDAP - - - - - - - common + + + + User + LDAP + + + + Role + LDAP + + + + Membership + LDAP + org.jboss.portal.identity.ldap.LDAPStaticRoleMembershipModule= Impl + + + + UserProfile + DELEGATING + + + + + DBDelegateUserProfile + DB + - - - - userCreateAttibutes - - - - - - - roleCreateAttibutes - - - - - - - ]]> - + + + + LDAPDelegateUserProfile + LDAP + + + + + + + common + + + + + + userCreateAttibutes + + + + + + + roleCreateAttibutes + + + + + + +]]> @@ -1060,8 +1030,7 @@ This is important as we will leverage them, and we want to synchr= onize users identity into default portal storage mechanism. So lets look at simple configuration that should take = place in jboss-portal.sar/conf/login-config.xml - - @@ -1103,9 +1072,7 @@ = - - ]]> - +]]> Few things are important in this configuration: Modified: docs/trunk/referenceGuide/en/modules/sso.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 --- docs/trunk/referenceGuide/en/modules/sso.xml 2007-04-17 13:20:32 UTC (r= ev 6985) +++ docs/trunk/referenceGuide/en/modules/sso.xml 2007-04-17 13:32:25 UTC (r= ev 6986) @@ -11,15 +11,15 @@ Overview of SSO in portal Portal as an integration and aggregation platform provides so= me form of SSO by itself. When you log into - portal you gain access to many systems accessed with portlets using= single identity. Still in many cases you - need to integrate portal infrastructure with other SSO enabled syst= ems. There are many different Identity Management - solutions on the market. In most cases each SSO framework provides = its own way to plug into JEE application. For custom configurations - you need to have good understanding of J= Boss Portal Identity management and authentication + the portal you gain access to many systems through portlets using a= single identity. Still in many cases you + need to integrate the portal infrastructure with other SSO enabled = systems. There are many different Identity Management + solutions on the market. In most cases each SSO framework provides = its own way to plug into Java EE application. For custom configurations + you need to have a good understanding of JBoss Portal Identity management and authentication mechanisms. Using Tomcat Valve - JBoss Application Server embeds Apache Tomcat as default serv= let container. Tomcat provides builtin SSO support + JBoss Application Server embeds Apache Tomcat as the default = servlet container. Tomcat provides a builtin SSO support using a valve. The Single Sign On Valve caches credentials on the s= erver side, and then invisibly authenticate users when they reach different web applications. Credentials are stored in a host-= wide session which means that SSO will be effective throughout the session. @@ -31,13 +31,12 @@ following line: - ]]> +]]> - Example usage + Example of usage Lets look a little bit closer and configure SSO between portal= and other web application. As an example we'll use jmx-console web-app that comes = with every JBoss Application Server installation. @@ -51,39 +50,38 @@ Edit $JBOSS_HOME/server/default/deploy/jmx-= console.war/WEB-INF/web.xml file and make sure it contains follo= wing content: - - HtmlAdaptor - An example security config that only allows users with= the - role JBossAdmin to access the HTML JMX console web application - - /* - GET - POST - - - Admin - - - - - Public - /public/* - GET - POST - - + + + HtmlAdaptor + An example security config that only allows users with the + role JBossAdmin to access the HTML JMX console web application + + /* + GET + POST + + + Admin + + = - - BASIC - jmx-console - + + + Public + /public/* + GET + POST + + = + + BASIC + jmx-console + = - - Admin - - ]]> + + Admin +]]> This will secure jmx-console web= application using BASIC browser authentication and restrict access for users with Admin role only. @@ -94,8 +92,7 @@ +admin=3DJBossAdmin,HttpInvoker,Admin]]> This file is a simple identity store for this web applic= ation authentication. It will make user admin belongs = to Admin role. @@ -129,8 +126,7 @@ following line: - ]]> +]]> --===============5346874970942006880==--