WebLogic 11g Security Concepts and Configuration

<< Previous [toc depth="3"]

Describe a WebLogic Server security realm

* Security Realms

* Security realm protects WL resources
* Each realm consists of a set of configured:
– security providers
– users: can be person or software entity
– groups: logically ordered set of users. Scoped to entire WLS domain.
– security roles:
~ privileges granted to user or group based on specific condition
~ are computed and granted dynamically
~ can be scoped to specific WL resources
– security policies:
~ an association between a WL resource and one or more users, groups, or security roles
~ protect against unauthorized access
* A user must be defined in sec realm in order to access any WL resources belonging to that realm

* Contains:
– Users
– Groups
– Sec roles
– Sec policies
– Credentials
* Can be:
– Embedded LDAP
– A property file
– Database
* Need to be initialized with default:
– Groups
– Sec roles
– Sec policies
* RDBMS sec store is needed for:
– XACML authn and role mapping providers
– WL Credential Mapping provider
– PKI Credential Mapping providers
– SAML 1.1 Identity Assertion provider v2, SAML 1.1 Credential Mapping provider v2
– SAML 2.0 Identity Assertion provider, SAMl 2.0 Credential Mapping provider
– Default certificate registry

* Modules that provide security services to applications
* See this post

* 1 or more per realm
* Supports:
– username/password
– certificate
– digest
* An Identity Assertion provider is a special type of Authentication provider and handles perimeter authentication and multiple sec token types and protocols.
* Login Modules perform actual authentication of a user or system
* Uses Principal Validation provider for signing and verifying principal authenticity

* 1 or more per realm
* Establish client identity using client supplied tokens, i.e. validate and map a token to username
* Enable perimeter authentication and SSO
* Support multiple token types (one token type per provider): Digest, SPNEGO, and SAML (1.1, 2.0)
* Can handle multiple sec protocols: Kerberos, SOAP, IIOP-CSIv2

* One Principal Validation provider per Authentication provider
* For Signing and verifying authenticity of principals
* Configured indirectly from the configuration of Authentication providers

* 1 or more per realm
* Controls access to WL resources based on sec policies
* Achieved by Access Decision
* Bulk access versions:
– BulkAuthorizationProvider
– BulkAccessDecision
* Return
– PERMIT
– DENY
– ABSTAIN

* Needed only for multiple Authorization Providers
* Resolves authorization conflicts from multiple Authorization Providers
* Bulk access version:
– BulkAdjudicationProvider
– BulkAdjudicator

* 1 or more per realm (if more than one, then results are merged)
* Support dynamic role associations based on
– Security roles from J2EE and WL deployment descriptor files
– Business logic and the current operation parameters
* Provides role information to Authentication providers
* Bulk operations:
– BulkRoleProvider
– BulkRoleMapper

* 0 or more per realm
* Collects, stores, distributes information about operating requests and their outcomes
* For non-repudiation
* Can write audit info to
– LDAP
– DB
– File

* 1 or more per realm (if more, results are combined)
* Maps WL credentials to legacy/remote credentials
* Allow WL to login legacy/remote systems on behalf of WL authenticated subjects
* Can handle different types of credentials
– username/password
– SAML
– PKI certificates

* 1 or more per realm (if more, need to pass all)
* Validate certificate chains
* Two CLS types:
– CertPath Builder: receives cert, cert chain, or cert ref from web service or application code, looks up and validates certificates in the chain
– CertPath Validator: receives cert chain from SSL protocol, web servicie, app code and perform extra validation such as revocation checking.

* Creates and manages password protected stores of private keys and trusted certs
* Deprecated, use JKS (Java Key Store) instead

* Provides backward compatibility with WL 6.x realms

* See Migrating Security Data

* Can only migrate using the same format
– A format is a data format that specifies how security data should be exported or imported
* Constraints are key/value pairs that specify import and export options. For example:
– passwords=cleartext
* Use passwords=cleartext to allow exporting password in clear text (does not work if passwords are one way hashed)
* Can use Admin Console or WLST
– WLST Example:

domainRuntime() 
cd('DomainServices/DomainRuntimeService/DomainConfiguration/mydomain/SecurityConfiguration/mydomain/DefaultRealm/myrealm/path-to-MBean/mbeanname')
cmo.importData(format,filename,constraints)

* Export page:

* Exported files:

* Import page:

* Export page:

* Exported file:

* Import page:

* See Manage users and groups

* See Manage security roles

* Global roles
* Scoped roles: applies to a specific instance of a WebLogic resource (such as a method on an EJB or a branch of a JNDI tree)

* Global Roles can not be removed (?) but Conditions can be removed.

* J2EE standard
* Uses only roles/policies defined in both J2EE DDs and WebLogic DDs
* WLS security admins verify existence of principals in WLS sec realm
* Changes recognized by WLS when redeployed

* Uses policies defined in J2EE DDs
* Ignores principal mappings in WLS DDs
* WLS sec admins use Admin Console to complete role mappings

* Unified and dynamic sec management
* Uses roles and policies created by sec admins
* Ignores all roles/policies defined in DDs
* Good for securing entire web apps or EJBs
* Not appropriate from fine grained control of large numbers of URL patterns and EJB methods

* Backward compatibility with WLS 9

* See Web Application Security-Related Deployment Descriptors

* Example:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>SecureOrdersEast</web-resource-name>
        <description>
            Security constraint for
            resources in the orders/east directory
        </description>
        <url-pattern>/orders/east/*</url-pattern>
        <http-method>POST</http-method>
        <http-method>GET</http-method>
    </web-resource-collection>
    <auth-constraint>
        <description>
            constraint for east coast sales
        </description>
        <role-name>east</role-name>
        <role-name>manager</role-name>
        </auth-constraint>
    <user-data-constraint>
        <description>SSL not required</description>
        <transport-guarantee>NONE</transport-guarantee>
    </user-data-constraint>
</security-constraint>

* web-resource-collection
– required
– defines components of the web app to which this security constraint is applied
*auth-constraint
– optional
– defines which groups or principals have access to the collection of Web resources defined in this security constraint.
* user-data-constraint
– optional
– defines how data communication between client and server should be protected (e.g. SSL)

* Contains the definition of a security role
* Sample web.xml:

  <servlet>
    <servlet-name>SnoopServlet</servlet-name>
    <servlet-class>extra.SnoopServlet</servlet-class>
    <run-as>
      <role-name>runasrole</role-name>
    </run-as>
  </servlet>
  <security-role>
    <role-name>runasrole</role-name>
  </security-role>

* Sample weblogic.xml:

  <weblogic-web-app>
     <run-as-role-assignment>
       <role-name>runasrole</role-name>
       <run-as-principal-name>joe</run-as-principal-name>
     </run-as-role-assignment>
  </weblogic-web-app>

* Links a security role name defined by <security-role> to an alternative role name that is hard-coded in the servlet logic.
* This extra layer of abstraction allows the servlet to be configured at deployment without changing servlet code.

Servlet code: 
out.println("Is the user a Manager? " +
                 request.isUserInRole("manager"));
web.xml entries:
<servlet>
. . .
   <role-name>manager</role-name>
   <role-link>mgr</role-link>
. . .
</servlet>
<security-role>
   <role-name>mgr</role-name>
</security-role>
weblogic.xml entries:
<security-role-assignment>
   <role-name>mgr</role-name>
   <principal-name>bostonManagers</principal-name>
   <principal-name>Bill</principal-name>
   <principal-name>Ralph</principal-name>
</security-role-ref>

* Explicitly indicate that you want the security roles defined by the role-name element in the web.xml deployment descriptors to use the mappings specified in the Administration Console
* Exmaple (webuser has to be defined in WLS realm)

web.xml entries:
<web-app>
           ...
           <security-role>
               <role-name>webuser</role-name>
           </security-role>
           ...
</web-app>
weblogic.xml entries:
<weblogic-web-app>
     <security-role-assignment>
         <role-name>webuser</role-name>
         <externally-defined/>
     </security-role-assignment>

* specifies the name of a principal to use for a security role defined by a run-as element in the companion web.xml file.

web.xml:
  <servlet>
    <servlet-name>SnoopServlet</servlet-name>
    <servlet-class>extra.SnoopServlet</servlet-class>
    <run-as>
      <role-name>runasrole</role-name>
    </run-as>
  </servlet>
  <security-role>
    <role-name>runasrole</role-name>
  </security-role>
weblogic.xml:
  <weblogic-web-app>
     <run-as-role-assignment>
       <role-name>runasrole</role-name>
       <run-as-principal-name>joe</run-as-principal-name>
     </run-as-role-assignment>
  </weblogic-web-app>

* Specifies a security permission that is associated with a Java EE Sandbox.

<weblogic-web-app>
   <security-permission>
     <description>Optional explanation goes here</description>
     <security-permission-spec>
<!--
A single grant statement following the syntax of
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax,
without the "codebase" and "signedBy" clauses, goes here. For example:
-->
      grant {
      permission java.net.SocketPermission "*", "resolve";
      };
     </security-permission-spec>
   </security-permission>
</weblogic-web-app>

* declares a mapping between a security role and one or more principals in the WebLogic Server security realm.
* Example

<weblogic-web-app>
  <security-role-assignment>
        <role-name>PayrollAdmin</role-name>
       <principal-name>Tanya</principal-name>
       <principal-name>Fred</principal-name>
       <principal-name>system</principal-name>
  </security-role-assignment>
</weblogic-web-app>

* javax.servlet.http.HttpServletRequest.getUserPrincipal()
* javax.servlet.http.HttpServletRequest.isUserInRole(String role)

* weblogic.servlet.security.ServletAuthentication
* weblogic.security.SimpleCallbackHandler

CallbackHandler handler = new SimpleCallbackHandler(username,
                                                               password);
Subject mySubject =
        weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// Where request is the httpservletrequest object.

* weblogic.security.URLCallbackHandler

CallbackHandler handler = new URLCallbackHandler(username,
                                                           password);
Subject mySubject =
        weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// Where request is the httpservletrequest object.

* See Configuring LDAP Authentication Providers

* Uses embedded LDAP server
* Supports any v2 or v3 compliant LDAP servers
* User names must be unique

Next >>

[mv_include id=’3268′]