在进行biee 角色迁移的时候，转载自该网站
http://oracamp.com/oracle-biee-11g-%E2%80%93-migrating-security-%E2%80%93-identity-stores-%E2%80%93-part-1
Oracle BIEE 11g – Migrating Security – Identity Stores – Part 1
One of the most important tasks while moving environments, say from Dev to Test or to Prod is in migrating the security objects. In 10g, it was a lot easier to move security as everything was embedded within the repository. But in the case of 11g, with the introduction of a lot of security related stores, the migration is not so straight-forward. In this blog post & the next, we shall be looking at the process of security migration in 2 areas
1. Full Migration
2. Incremental Migration
In BI EE 11g, as we have covered in detail before here and here, there are some new security related stores. They are
1. Identity Store
2. Policy Store
3. Credential Store
4. Key Store
So migration of security in BI EE 11g entails moving all the above stores from one environment to the other. Its not necessary that we have to migrate all the stores. BI EE 11g, provides that flexibility where we can pick and choose which stores that we want to migrate and which ones we can keep as constant across environments. This blog post will cover only the file based security migration (assuming no LDAP is used for any of the above stores)
Identity Store:
Identity store migration basically entails migrating Weblogic Embedded LDAP server Users and Groups from one environment to the other. To draw a parallel with 10g, whenever we move RPD from one environment to the other, the users stored within the RPD(in 10g) get migrated automatically. But in BI EE 11g, since an embedded LDAP server is used for storing the users, we will have to migrate the users & groups manually from one environment to the other.
Full Migration on a brand new Realm:
In many cases, we might want to move all the users/groups defined in one environment to the other. This is called as the Full Migration. Weblogic supports export of the entire LDAP directory. So, to do an export, we log on to the Weblogic Console and navigate to the Migration tab within the default security realm (myrealm).
Under the Export tab, specify the directory where you want the users/groups to be exported to and click on Save.
As soon as you save, you should see .dat files created under the directory.
You will notice that it not only exports the users and groups but also the roles and policies. But be aware that the roles and policies are not BI EE roles and policies. Instead they are the policies specific Admin Server.
Now to test the import process, lets create a new security realm called newrealm.
Within this realm, lets create the 2 providers that we get by default whenever we install BI EE i.e. DefaultAuthenticator and DefaultIdentityAsserter(we need to have the existing providers that were present during the export).
Activate the changes and restart the Admin Server. After the restart, lets navigate to the Migration Section of the newrealm and specify the directory of the exported files.
You should get a warning stating that CredentialMapper, XACMLRoleMapper & XACMLAuthorizer providers are missing. For now we can neglect this error as ideally when you do the migration, it will be on a realm where BI EE will have all these providers configured by default. So, you should not be getting these warnings when doing an actual migration into an existing BI EE realm.
But you will notice that users and groups have been imported successfully as we have created the DefaultAuthenticator provider. So, lets go to the Users and Groups tab of the DefaultAuthenticator provider in the newrealm.
As you see, we now have the users that were there in the DefaultAuthenticator of the default realm myrealm migrated to the newrealm.
Full Migration on an existing BI EE Realm:
We saw some warnings when we imported the security into a new realm above. Also, we haven’t covered what exactly the import export process does. To understand, lets take 2 BI EE instances with the defaultrealm pre-configured. One is a dev instance and the other is a Prod instance. To understand what exactly happens during the import export process lets take the example of 3 users.
1. User1 – Exists in Dev instance alone.
2. User2 – Exists in Dev and Prod instance. But the passwords, descriptions are different in both the instances.
3. User3 – Exists in Prod instance alone
So, this is what we have in the Dev instance.
This is what we have in the Prod instance
Lets now take an export of the Dev instance and then import into the Prod instance. The steps are exactly the same as above. We need to move the exported files manually on to the Prod server.
As you see now, there are no warnings during the import. Lets now take a look at the users in the Prod instance.
If you notice, we now have the User1 imported into the authenticator. But the attributes of the Prod instance user User2 has not be overwritten by the Dev instance. This makes sense as generally during the import process we do not want existing artifacts in Prod to be overwritten by the ones in Dev.
Incremental Migration – Automating User Creation & Group Assignments using WLST:
So far what we saw above was a means of manually migrating the complete provider from one instance to the other. In many cases, we might want to migrate users and groups incrementally and automatically. To do that weblogic supports a scripting methodology called as WLST which can be used to automate just about every aspect of weblogic. I will be covering the use cases of WLST in more detail in the coming weeks. But for now, lets see how to use WLST to automatically create users and groups(all in interactive mode – we can automate this but that is something i will cover in future). Also, if you would like to use Java API instead of WLST that is also possible using JMX bean scripting interface. I have covered that already here.
There are multiple entry points into WLST in BI EE 11g. The recommended binary to startup the WLST in BI EE 11g resides under the {Oracle_BI1}\common\bin directory. This sets up all the necessary jars in the classpath. So start up the wlst.cmd/wlst.sh from command line.
Enter the command
connect(“weblogic”,”welcome1″,”localhost:7001″)
Get the DefaultAuthenticator MBean using the following command.
atnr=cmo.getSecurityConfiguration().getDefaultRealm().lookupAuthenticationProvider(“DefaultAuthenticator”)
Now create a new user using the command shown below
atnr.createUser(‘wlstuser’,’welcome1′,’WLST User’)
This should create the user automatically.
In the same way we can automate the user-group assignment and everything else. All the front-end tasks that are done from the EM or the CONSOLE can be automated completely. In the next blog post, lets look at how to go about migrating the policy store and the credential store
------------------------------------------------------------------------------------------------------------------------------
Oracle BI EE 11g – Migrating Security – Policy Store – Part 2
In the last post, we saw how to go about doing a security migration of the Identity Stores. Today we shall look at the migration process of the Policy Stores. Just to give a brief background, Policy Store is nothing but a physical file that contains the Application Role, Applications Policies and their corresponding mapping to the Weblogic Users and Groups. So, anything that is accessible from within the EM Security Page (shown below) will be present within the Policy Store. In BI EE 11g, the entire Policy Store exists as a single file called as the system-jazn-data.xml. This file generally exists under {Middleware_Home}/user_projects/domains/bifoundation_domain/config/fmwconfig directory.
To illustrate, shown below are a couple of screenshots. The first screenshot contains the actual EM UI where Application Roles are created or modified. The second screenshot shows how the roles that are created in the EM UI are stored within the system-jazn-data.xml file.
Migrating application roles from one environment to another is even more important as generally the Application Roles will more or less be the same across environments. In BI EE 10g, as the GROUPs were maintained within the RPD, there was no additional need to move the GROUPs separately. But in BI EE 11g, the Application Roles will have to be moved separately. Lets look at the possible ways of migrating the application roles from one environment to the other
Full Migration of Application Roles using WLST:
Unlike Identity Stores where we had an option to export the entire embedded LDAP provider, there is no such option for application roles. So, to move application roles we will have to use Weblogic Scripting (WLST). Let’s again take the example of 2 environments Dev and Prod. In Production we have the following Application Roles.
1. BISystem
2. BIAdministrator
3. BIAuthor
4. BIConsumer
5. ReportAuthor
6. ReportDeveloper
In the Dev environment, we have the following Application Roles.
1. BISystem
2. BIAdministrator
3. BIAuthor
4. BIConsumer
5. ReportAuthor
6. ReportConsumer
Basically there are 3 main differences between the Dev and Prod environments.
1. ReportAuthor role exists in both environments. But weblogic user is assigned to this role in Prod but not in Dev.
2. ReportConsumer role exists only in Dev.
3. ReportDeveloper role exists only in Prod.
To migrate security there is a WLST method called as MigrateSecurityStore which can move the roles from one system-jazn-data.xml to the other. To do that, we need to first copy the system-jazn-data.xml from Dev instance to the Prod instance (to a temporary directory). In the same way copy the system-jazn-data.xml from the Prod instance to the temporary directory as shown below.
Also, take a backup of all these files before doing the migration. Now, copy the jps-config.xml from any one of the instances (Dev or Prod) to the temporary Directory as shown below. And rename the file to jps-config-policy.xml.
Open up the jps-config-policy.xml. You will notice that this file contains all the details about all the stores in the environment. Now, for policy migration, we need to basically use this file to point to the locations of the Dev and Prod (source & target) system-jazn-data.xml files. Also, since we are doing only policy migration, we do not need the other store related tags within this file. Remember that we are modifying only a copy of the jps-config.xml. This copy file will be used only for migration. The modified file is given below
Now that we have our jps-config file ready, navigate to the temporary directory from command prompt and initialize the WLST using the following command.
In WLST, application role migration can be done even in offline mode. So, effectively there is no need for us to connect to the weblogic admin server. In offline interactive mode, fire the following command
migrateSecurityStore(type=”appPolicies”, srcApp=”obi”, configFile=”C:/SecurityMigration/jps-config-policy.xml”, src=”sourceFileStore”, dst=”targetFileStore”, overWrite=”false”)
You will see a lot of warnings like Identity Store not found etc. These can be safely neglected as we are only moving the policy store. If you now open up the Prod system-jazn-data.xml (under the temporary directory), you will see that the application role which existed only in Dev (ReportConsumer) would now exist in this file as well.
To understand what exactly happened, lets stop the Prod BI EE instance and overwrite the existing system-jazn-data.xml file with the migrated one. If we now look at the list of roles in the EM, you will notice that a merge has happened (with no overwrites on existing roles in Prod).
But if you notice, the weblogic user which was assigned to the ReportConsumer role in Dev has not been migrated. Let’s find out why. Maybe it’s because our jps-config-policy.xml did not have the connectivity to identity stores, it was not able to migrate the weblogic user. To validate this, lets go back to the dev environment and assign the BIConsumer role to the ReportConsumer role. Also, lets add ReportDeveloper role as well but with BIAuthor role assigned as shown below.
Let’s now run the Migration again. Again neglect the warnings and restart the BI Services with the migrated security-jazn-data.xml file.
Even now its the same. The member assignments are not carried over during the migration. I am not sure whether it is a bug or an intended behaviour. But be aware of the fact that while doing the app role migration, the member assignments are not carried over. We will have to reapply the assignments post migration.
Incremental Migration of Application Roles using WLST:
As shown above, full migration cannot migrate the member assignments of an application role. Also, full migration does not allow us to pick and choose the roles that we would like to move. To do an incremental Role by Role migration (and to automate it), there are a separate set of WLST commands that can be put to use. We will start off with some simple ones and then move on to the actual incremental migration.
Listing Application Roles using WLST:
The first command we will see is used for listing the complete application roles that we have as part of BI EE. This command is what is used internally by the EM to display the list of Application Roles. The command for that is given below
connect(“weblogic”,”welcome1″,”localhost:7001″)
listAppRoles(“obi”)
Listing Application Role Members using WLST:
To list all the members that are present within a role, there is a command called as listAppRoleMembers which can give us the complete listing. Again, this is what is used by EM internally to extract all the member related information of a specific Application role.
connect(“weblogic”,”welcome1″,”localhost:7001″)
listAppRoleMembers(“obi”,”BIConsumer”)
Creating Application Roles using WLST:
To create a new role using WLST, there is a command called as createAppRole which can create roles automatically. For example, lets create a new Role called as ReportWLSTRole from the command line and see whether that appears within the EM.
connect(“weblogic”,”welcome1″,”localhost:7001″)
createAppRole(“obi”,”ReportWLSTRole”)
Assigning Members to an Application Role using WLST:
And finally to automatically assign members to an application role, we can use the grantAppRole command. An example of the command is given below. Here a weblogic user, weblogic group and an App Role are assigned to the newly created Application Role.
connect(“weblogic”,”welcome1″,”localhost:7001″)
grantAppRole(“obi”,”ReportWLSTRole”,”oracle.security.jps.service.policystore.ApplicationRole”,”BIAuthor”)
grantAppRole(“obi”,”ReportWLSTRole”,”weblogic.security.principal.WLSUserImpl”,”weblogic”)
grantAppRole(“obi”,”ReportWLSTRole”,”weblogic.security.principal.WLSGroupImpl”,”BIAdministrators”)
To do an incremental migration will be using a mix of all the commands above to automate the entire process. During my WLST automation blog post later this month, i will upload a script that will automatically do all the above processes in the backend (not interactive)
---------------------------------------
Oracle BI EE 11g – Migrating Security – Credential Store – Part 3
In the last 2 posts we saw the process involved in migrating the Identity as well as the Policy Stores. In today’s post we shall see the process involved in migrating Credential Stores from one environment to the other. To recap, Credential Stores are nothing but a physical file that holds the credential details of other systems in an encrypted format. The credential store can be SSL enabled where in to even get inside the store will require a SSL certficate. Basically all the credentials are stored inside a file called as cwallet.sso. This is the file that holds all the credential entries. This file will be present under {Middleware_Home}\user_projects\domains\bifoundation_domain\config\fmwconfig. We will again explore the 2 different types of migration for credential stores.
Full Migration:
In the case of Credential Stores its not recommended to do full migration. The main reason for this is, there are certain Credential Maps like oracle.bi.system and oracle.bi.enterprise which contain instance specific usernames and passwords. So, migrating these from one environment to the other will overwrite these keys which might even render the instance unusable. But if at all the intention is to just clone the environment then we can use the migrateSecurityStore method that i wrote on the PolicyStore to do a full migration. The syntax is exactly similar to what we did during the full migration policy store.
migrateSecurityStore(“credStore”,configFile=”C:/SecurityMigration/jps-config-cred.xml”,src=”sourcecredstore”,dst=”targetcredstore”)
Given below is the sample jps-config-cred.xml that you can use for the migration.
Incremental Migration using WLST:
We can do incremental Credential Store migration using wlst methods like createCred(). To illustrate lets consider a scenario that is very similar to what we had in the last 2 blog posts i.e. we have 2 environments Dev and Prod. Development environment has the following Credentials Stored.
In Production environment, the following are the list of credentials.
So basically we have a new Credential Map called as DevMap which needs to be migrated to the production environment. Even though there are differences in the keys within oracle.bi.enterprise map, we would not like to migrate them as they are environment specific.
Listing the Credential in Dev Environment:
All the Credential Keys are generally stored in an encrypted format (the passwords). So, to migrate we will need to first extract these passwords and then do the migration to Production. The passwords can be extracted through the listCred() method of WLST. We need to be connected to the Admin Server for this method to work. The exact command is given below
connect(“weblogic”,”welcome1″,”localhost:7001″)
listCred(“DevMap”,”DevKey”)
This will show the encrypted password entered inside the key as shown below
And this is what we see in the enterprise manager.
As you see, with listCred we are able to extract the full credentials. Now, lets try to see what is the default password for the BISystemUser.
listCred(“oracle.bi.system”,”system.user”)
In the same way lets extract the passwords of the SampleAppLite repository.
listCred(“oracle.bi.enterprise”,”repository.SampleAppLite”)
With this we can even extract the lost Repository passwords.
Creating a new Credential in the Prod Environment:
Now that we have extracted the key details from Dev, using wlst we can create these directly into Production using the createCred method.
createCred(map=”ProdMap”,key=”ProdKey”,user=”system”,password=”welcome1″,desc=”Test”)
If we now login to EM, we should see the Credential created in Prod environment.
This concludes my series on the security migration for BI EE 11g
相关推荐
Of course, a migration from any database is not something to be taken lightly, and so countless organizations are considering their options for migrating to MySQL. In particular, many MySQL customers...
### 从Struts1迁移到Struts2 #### 引言 随着技术的发展与进步，Struts1作为曾经广泛使用的Web应用框架，逐渐被Struts2等新一代框架所取代。Struts2以其更加灵活的设计、丰富的特性以及更好的性能表现成为众多开发者...
2. **Pivotal平台** Pivotal Cloud Foundry（PCF）是Pivotal提供的云原生平台，它集成了上述云原生理念，提供了统一的运行时环境，支持多种编程语言，并且与各种云基础设施良好集成。PCF的特性包括应用部署和管理、...
Mitigate the risks involved in migrating away from a proprietary database platform toward MariaDB’s open source database engine. This book will help you assess the risks and the work involved, and ...
《自组织迁移算法：方法论与实施》是一本关于智能计算领域的电子书，它涵盖了自组织迁移算法（Self-Organizing Migrating Algorithm, SOMA）的原理、应用和设计方法。这本书是《计算智能系列》的一部分，由Donald ...
Migrating to Microservices Databases,Migrating to Microservices Databases
Cloud computing is one of most booming fields nowadays, and many of the big organizations, as well as start-ups, are now migrating to a cloud platform to their websites and applications from ...
2. **标准化外设接入**：除了VR头显，开发者还可以通过OSVR获得标准化的外设接入，如眼动追踪器、手势摄像头等。 3. **开源透明性**：作为一款开源平台，OSVR具有高度透明度，开发者可以根据需求进行定制和增强。 ...
### 迁移应用程序至Flex 2 随着技术的不断进步和发展，软件开发工具和技术也在不断地迭代更新。Adobe Flex 2 是一个重要的里程碑，它为开发者提供了更为强大的功能和更丰富的用户体验。本文旨在介绍如何将现有的...
2. **容器化**：使用轻量级容器（如Docker）来封装应用程序及其依赖项，确保一致性和可移植性。 3. **持续集成与持续部署(CI/CD)**：自动化测试和部署过程，以快速可靠地交付软件更新。 4. **十二因子应用**：一种...
云计算和微服务架构是当前信息技术领域中变革性的发展方向，它们重新定义了传统软件架构的边界，使得应用设计更加灵活、可扩展，以及更符合现代业务需求的持续集成和持续部署（CI/CD）流程。《迁移到云原生应用架构...
本文章基于"Migrating-VxWorks-apps-to-embedded-Linux-slides-with-notes.pdf"文件中的内容，深入探讨了将VxWorks应用程序迁移到嵌入式Linux的关键考量因素、迁移路径的选择以及实施过程中的注意事项。 ### ...
Adoption of cloud-native application architectures is helping many organizations transform their IT into a force for true agility in the marketplace. This O’Reilly report defines the unique ...