Showing posts with label was7. Show all posts
Showing posts with label was7. Show all posts

Fine grained security in WAS

The WebSphere Application Server has concept of fine grained security, which means you can assign a user rights to individual resource instead of the full cell. For example you want to allow a dev team to update only there enterprise application, but you dont want them to modify any other applications or any other configuration, you can do that with fine grained security configuration.

I wanted to try this feature so i did create a HelloFineGrainedSecurityEAR application and i want to configure the security so that only users in devteam group will be able to deploy only HelloFineGrainedSecurityEAR application, i followed these steps

  • First i followed the instructions in the Assiginging administrative roles to user entry to assign monitor role to devteam group

  • I went to Security -> Administrative Authorization Group screen in the WAS Admin Console


  • I clicked on New to create a new Administrative Authorization Group like this

    I did create HelloFineGrainedSecurityAdminGroup and i did select HelloFineGrainedSecurityEAR application because thats the only application that i want this group to modify

  • Then i clicked on Administrative Group roles link to assign a group deployer role to the HelloFineGrainedSecurityAdminGroup




  • Now when i log out and login using one of the group in the devteam, and i went to Manage application section and i can see that i do have access to update HelloFineGrainedSecurityEAR but not any other application


Assiginging administrative roles to user

In most of the organizations only WAS Admin or Infrastructure team has access to WAS Admin Console, but sometimes members of your development team might want limited access to the WAS Admin console so that they can view the current configuration or you might want to allow them to stop and start server (I think its OK to allow development team to view current configuration in Development environment, but the security team might not allow them access to WAS Admin console in the QA or Production environment )

I wanted to check if i can allow development team to access the admin console so that they can view the configuration but not change it. In order to do that i had to first create a devteam group, add couple of users to that group and then assign Monitor role to the devtream group. In my case i am using default WAS installation so i am using Federated repository to store user configuration. I followed these steps


  • Login into the WAS Admin Console and go to Users and Group -< Manage Groups


  • Click on Create button to start creation of new group


  • Then go to Users and Group -< Manage User to look at the list of users


  • Click on create button and start creation of new user, Sunil


  • Go back to Manage Groups select the devteam group and add Sunil and Jiya as member to the devtream group


  • Now our devteam group is ready with the members and next step is to assign Monitor role to the devteam. For that first go to Security -< Global Security and click on Administer Group Roles


  • You should see list of existing group roles like this


  • Click on create and on the next screen click assign Monitor role to the devteam


  • You should be able to see the role assignment for the devteam group


  • Save your changes and restart the server, now you should be able to login into WAS Admin Console using one of the members in the devteam and you will notice that the configuration is read only




How to stop WAS + WPS without passing userId and password to stopserver

If admin security is enabled on the WAS server you will have to specify the user name and password when you want to stop the WAS server, You can run the following command to do that

./stopServer.sh server1 -username wasadmin -password wasadmin


For WebSphere Application Server running under a UNIX-based operating system (OS), the previously mentioned command (the UNIX equivalent) carries a serious security problem. Anybody who uses the command ps -ef while the stopServer process is running is able to see the user ID and the password.

In order to solve this problem you can follow these steps

  1. First open the /WebSphere/AppServer/profiles/AppSrv01/properties/soap.client.props file in the text editor and change value of following three properties

    com.ibm.SOAP.securityEnabled=true
    com.ibm.SOAP.loginUserid=wasadmin
    com.ibm.SOAP.loginPassword=wasadmin

    The value of com.ibm.SOAP.loginUserid should be equal to the name of the wasadmin user and the value of com.ibm.SOAP.loginPassword would be equal to password for the wasadmin


  2. Since your storing the password in plain text in the .properties file someone can read it to deal with that issue you should use the PropFilePasswordEncoder.sh command with the fully qualified file name and the name of the property that holds the password

    ./PropFilePasswordEncoder.sh /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/properties/soap.client.props com.ibm.SOAP.loginPassword

    After running this command if you open the soap.client.props file in the text editor you will notice that value of the password is encoded

    com.ibm.SOAP.securityEnabled=true

    #------------------------------------------------------------------------------
    # - authenticationTarget ( BasicAuth[default], KRB5. These are the only supported selection
    # on a pure client for JMX SOAP Connector Client. )
    #------------------------------------------------------------------------------
    com.ibm.SOAP.authenticationTarget=BasicAuth

    com.ibm.SOAP.loginUserid=wasadmin

    com.ibm.SOAP.loginPassword={xor}KD4sPjsyNjE=



  3. Restart the server and after that you wont have to use the password on the command line to stop the server

Property based configuration in WAS7

The WebSphere Application Server V7.0 has concept of properties file based configuration. The basic idea is that you can extract configuration of existing object into .properties file, modify that properties file, validate and import it back in the WAS server to change the object.

I wanted to try this feature so i first i created a SampleDataSource on my machine, the SampleDataSource is bound to jdbc/sampleds, name in the JNDI namespace



Then i opened a wsadmin command prompt to connect to WAS, and i executed this command

AdminTask.extractConfigProperties('-configData DataSource=SampleDataSource -propertiesFileName /tmp/sampleds.properties')


The AdminTask.extractConfigProperties() method lets you retrieve configuration of object into properties file, the value of -configData argument gives name of the object that you want to export, In my case i am saying export DataSource object with name equal to SampleDataSource and export it into /tmp/sampleds.properties.

This is how the sampleds.properties file looks like, as you can see all the configuration is exported in key value pairs.



#
# Configuration properties file for cells/localhostNode01Cell/nodes/localhostNode01/servers/server1|resources.xml#DataSource_1300824072894#
# Extracted on Tue Mar 22 16:07:09 EDT 2011
#

#
# Section 1.0 ## Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=ID#JDBCProvider_1300823613457:DataSource=ID#DataSource_1300824072894
#

#
# SubSection 1.0.0 # DataSource attributes
#
ResourceType=DataSource
ImplementingResourceType=GenericType
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=ID#JDBCProvider_1300823613457:DataSource=ID#DataSource_1300824072894
#

#
#Properties
#
name=SampleDataSource
category=null
datasourceHelperClassname=com.ibm.websphere.rsadapter.DerbyNetworkServerDataStoreHelper
authMechanismPreference=BASIC_PASSWORD #ENUM(BASIC_PASSWORD|KERBEROS)
statementCacheSize=10 #integer
providerType=Derby Network Server Using Derby Client #readonly

jndiName="jdbc/sampledatasource"

relationalResourceAdapter=WebSphere Relational Resource Adapter #ObjectName(J2CResourceAdapter)
xaRecoveryAuthAlias=null
diagnoseConnectionUsage=false #boolean
authDataAlias=
manageCachedHandles=false #boolean
provider=DerbyNetworkServerUsingDerbyClient #ObjectName(JDBCProvider),readonly
description=New Network Server JDBC Datasource that uses Derby Network Client. This Datasource type is only configurable in version 6.1 and later nodes
logMissingTransactionContext=true #boolean


#
# SubSection 1.0.0.0 # ConnectionPool attributes
#
ResourceType=ConnectionPool
ImplementingResourceType=GenericType
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=ID#JDBCProvider_1300823613457:DataSource=ID#DataSource_1300824072894:ConnectionPool=ID#ConnectionPool_1300824072899
AttributeInfo=connectionPool
#

#
#Properties
#
stuckThreshold=0 #integer
unusedTimeout=1800 #long
maxConnections=10 #integer
stuckTimerTime=0 #integer
testConnectionInterval=0 #integer
minConnections=1 #integer
surgeThreshold=-1 #integer
connectionTimeout=180 #long
purgePolicy=EntirePool #ENUM(EntirePool|FailingConnectionOnly)
surgeCreationInterval=0 #integer
numberOfUnsharedPoolPartitions=0 #integer
stuckTime=0 #integer
agedTimeout=0 #long
reapTime=180 #long
testConnection=false #boolean
numberOfSharedPoolPartitions=0 #integer
freePoolDistributionTableSize=0 #integer
numberOfFreePoolPartitions=0 #integer


#
# SubSection 1.0.0.1 # ConnectionTest attributes
#
ResourceType=ConnectionTest
ImplementingResourceType=GenericType
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=ID#JDBCProvider_1300823613457:DataSource=ID#DataSource_1300824072894
AttributeInfo=preTestConfig
#

#
#Properties
#
preTestConnection=null #boolean
retryLimit=null #integer
retryInterval=null #integer


#
# SubSection 1.0.0.2 # DataSource J2EE Properties
#
ResourceType=J2EEResourcePropertySet
ImplementingResourceType=GenericType
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=ID#JDBCProvider_1300823613457:DataSource=ID#DataSource_1300824072894:J2EEResourcePropertySet=ID#J2EEResourcePropertySet_1300824072898
AttributeInfo=resourceProperties(name,value)
#

#
#Properties
#
dataSourceName= #String
webSphereDefaultIsolationLevel= #integer
nonTransactionalDataSource=false #boolean
freeResourcesOnClose=false #boolean
portNumber=1527 #integer
reauthentication=false #boolean
connectionAttributes= #String
preTestSQLString=SELECT CURRENT SQLID FROM SYSIBM.SYSDUMMY1 #String
serverName=localhost #String
validateNewConnection=false #boolean
validateNewConnectionRetryCount=100 #integer
traceFile= #String
connectionSharing=1 #integer
beginTranForResultSetScrollingAPIs=false #boolean
enableMultithreadedAccessDetection=false #boolean
retrieveMessageText=true #boolean
description= #String
userDefinedErrorMap= #String
errorDetectionModel=ExceptionMapping #String
jmsOnePhaseOptimization=false #boolean
beginTranForVendorAPIs=false #boolean
databaseName=/temp/sampleds;create=true #String,required
validateNewConnectionRetryInterval=3 #long
traceLevel= #integer


#
# SubSection 1.0.0.3 # DataSource Custom Properties
#
ResourceType=DataSource
ImplementingResourceType=GenericType
ResourceId=Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=ID#JDBCProvider_1300823613457:DataSource=ID#DataSource_1300824072894
AttributeInfo=properties(name,value)
#

#
#Properties
#


#
# End of Section 1.0# Cell=!{cellName}:Node=!{nodeName}:Server=!{serverName}:JDBCProvider=ID#JDBCProvider_1300823613457:DataSource=ID#DataSource_1300824072894
#
#
#
EnvironmentVariablesSection
#
#
#Environment Variables
cellName=localhostNode01Cell
serverName=server1
nodeName=localhostNode01



I changed value of jndiName property to jdbc/sampledatasource and saved the file, then i used following command to validate the sampleds.properties file


AdminTask.validateConfigProperties('-propertiesFileName /tmp/sampleds.properties')


If the configuration is valid it returns true, if the configuration is valid you can executed AdminTask.applyConfigProperties() command to apply the configuration defined in the sampleds.properties file to the server


AdminTask.applyConfigProperties('-propertiesFileName /tmp/sampleds.properties -validate true')
AdminConfig.save()


Dont forget to call AdminConfig.save() to actually commit your changes, if you dont call it then your changes will be lost