Jun 30

Introduction
To secure your website you can set the security permissions on individual web pages, web services and sub directories. ASP.NET supports this requirement with declarative authorization rules. These rules are defined in the web.config file. The rules you define in the web.config file, are acted upon by the URL Authorization Module, a specific HTTP module. This module examines the defined rules and checks each request to make sure user can’t access resources which are restricted from the users.

Following diagram describe the workflow of the FormsAuthenticationModule, and the UrlAuthorizationModule when an unauthorized request arrives. In particular, diagram shows a request by an anonymous visitor for ProtectedPage.aspx, which is a page that denies access to anonymous users. Since the visitor is anonymous, the UrlAuthorizationModule aborts the request and returns an HTTP 401 Unauthorized status. The FormsAuthenticationModule then converts the 401 status into a 302 Redirect to login page. After the user is authenticated via the login page, he is redirected to ProtectedPage.aspx. This time the FormsAuthenticationModule identifies the user based on his authentication ticket. Now that the visitor is authenticated, the UrlAuthorizationModule permits access to the page.

Authorization Rules:
Authorization determines whether an identity should be granted access to a specific resource.Authorization rules are defined in the <authorization>element in the <system.web> section of the web.config file apply to all of the ASP.NET resources in that directory and its sub directories (until otherwise overridden by another Web.config file). There are two types of rules exists: allow and deny. You can allow or deny users, roles (group of users).You can add verbs attribute to create a rule that applies only to specific type of HTTP requests (GET, POST, HEAD and Debug).
The basic structure of the authorization is as follows:

You can add as many allow and deny rules as you want.
To deny access to all anonymous users, you can use a deny rules like this:

To allow access to all users you can use:

The question mark (?) is a wildcard that represents all users with unknown identities.  The asterisk(*) represents all users including authenticated and anonymous users.You can add more than one rule in authorization section.
Consider the following rule:

This rule will allow all users to access the resources. ASP.NET will evaluate first rule which allow access to all usres and it will not evaluate the second rule since we already have provided access to all users in the first line. However reversing the lines of rules the following authorization rule will deny all anonymous users and allow access to all other users.

Controlling access to specific users:
You can grant access on the base of user accounts.
Let us consider the following authorization rule.

This rule will allow access to only listed users i.e amit, amitkumar, sandeep
And restrict all other users, even if they are authenticated.
Here is an another example:

In this rule the listed users i.e amit,amitkumar,sandeep are strictly restricted to allow access.Let us take another example.

In the above example users amit,amitkumar are denied. But it does not affect the user sandeep, because asp.net matches the rule that allows all users and doesn’t read any further

Controlling access to specific sub directories:
You can set authorization rules to specific directories. You just need to add the web.config file in the sub directory with the authorization rules as per your requirement.
Remember that when you add the web.config file in the sub directories, it should not contain any of the application-specific settings. In fact it should contain only the authorization information as shown below:

When using authorization rules to specific directories, ASP.NET still reads the authorization rules from the parent directory, but it applies the subdirectory rules first.
Let us clear this point using an example.
You have define a rule in the root virtual directory as below:

And the sub directory contains the rule as:

In this case user amitkumar will be able to access any resource in the root directory but no resources in the sub directories.

If you reverse these rules then user amitkumar will be able to access the resources of sub directories but will not be able to access resources of the root directory.

ASP.NET allows unlimited hierarchy of sub directories and authorization rules to make the real life problems very easy.

Controlling access to specified files:
Setting file access permissions by directory is the cleanest and easiest approach. However, you can also restrict specific files by adding <location>tags in the web.config file.
Consider the following:


In the above setting all users are restricted to access the restrictedPage.aspx page.

Controlling access for specific roles:
To make the website security easier users are grouped into the categories called roles. Suppose you need to manage an enterprise applications that supports thousands of users, it will be difficult to apply restrictions on thousands of users individually. So users are grouped into roles. So the rules applied to the specific role will be applicable to all the users with in the role. You can create as many roles as you want.
When you use role based authorization,  you must enable roleManager in the web.config file in the <system.web> section.


For example the following authorization rules allows access to two users amit and amitkumar and two roles admin and management and all other users are denied.


ASP.NET makes it easy to define user-based authorization rules. With just a bit of markup in Web.config, specific web pages or entire directories can be locked down so that they are only accessible to a specified subset of users. Page-level functionality can be turned on or off based on the currently logged in user through programmatic and declarative means.

Tagged with:
Jun 28

Table Partitions
Partitioned tables allow your data to be broken down into smaller, more manageable pieces called Partitions, or even Sub Partitions. Indexes can be partitioned in similar fashion. Each partition is stored in its own segment and can be managed individually.
SQL queries and DML statements do not need to be modified in order to access partitioned tables.
However, after partitions are defined, DDL statements can access and manipulate individual partitions rather than entire tables or indexes. This is how partitioning can simplify the manageability of large database objects and enables faster data access within an Oracle database.

Partitioning allows tables and indexes to be partitioned into smaller, more manageable units, providing database administrators with the ability to pursue a “divide and conquer” approach to data management. With partitioning, maintenance operations can be focused on particular portions of tables. For example, a database administrator could back up a single partition of a table, rather than backing up the entire table.

Advantages of Partitioning:
• It enables data management operations such as data loads, index creation and rebuilding, and backup/recovery at the partition level, rather than on the entire table. This results in significantly reduced times for these operations.
• It improves query performance. In many cases, the results of a query can be achieved by accessing a subset of partitions, rather than the entire table.
• It increases the availability of mission-critical databases if critical tables and indexes are divided into partitions to reduce the maintenance windows, recovery times, and impact of failures.

Figure 1 List, Range, and Hash Partitioning

Types of Table Partitions

There are several partitioning methods offered by Oracle Database. Here, we have to discuss three basic partitions:

Range Partitioning
Range partitioning is used when partitions based on ranges of column values. This type of partitioning is useful when dealing with data that has logical ranges into which it can be distributed; for example, months of the year. Performance is best when the data evenly distributes across the range.

Range Partitioning Example
CREATE TABLE Sales_Range
(salesman_id NUMBER(5),
salesman_name VARCHAR2(30),
sales_amount NUMBER(10), sales_date DATE)
PARTITION BY RANGE(sales_date)

(PARTITION sales_jan2010 VALUES LESS THAN(TO_DATE(’02/01/2010′,’DD/MM/YYYY’)),
PARTITION sales_feb2010 VALUES LESS THAN(TO_DATE(’03/01/2010′,’DD/MM/YYYY’)),
PARTITION sales_mar2010 VALUES LESS THAN(TO_DATE(’04/01/2010′,’DD/MM/YYYY’)),
PARTITION sales_apr2010 VALUES LESS THAN(TO_DATE(’05/01/2010′,’DD/MM/YYYY’))
);

Hash Partitioning
Use hash partitioning if your data does not easily lend itself to range partitioning, but you would like to partition for performance and manageability reasons. Hash partitioning provides a method of evenly distributing data across a specified number of partitions. Rows are mapped into partitions based on a hash value of the partitioning key.

Hash Partitioning Example
CREATE TABLE Sales_Hash
(salesman_id NUMBER(5),
salesman_name VARCHAR2 (30),
sales_amount NUMBER(10),
week_no NUMBER(2))
PARTITION BY HASH(salesman_id)
PARTITIONS 4 STORE IN (data1, data2, data3, data4)

The preceding statement creates a table sales_hash, which is hash partitioned on salesman_id field. The tablespace names are data1, data2, data3, and data4.

List Partitioning
List partitioning is used when you require explicit control over how rows map to partitions. You can specify a list of discrete values for the partitioning column in the description for each partition. This is different from range partitioning, where a range of values is associated with a partition, and from hash partitioning, where the user has no control of the row to partition mapping.

The list partitioning method is specifically designed for modeling data distributions that follow discrete values. This cannot be easily done by range or hash partitioning because:

• Range partitioning assumes a natural range of values for the partitioning column. It is not possible to group together out-of-range values partitions.
• Hash partitioning allows no control over the distribution of data because the data is distributed over the various partitions using the system hash function. Again, this makes it impossible to logically group together discrete values for the partitioning columns into partitions.

Unlike the range and hash partitioning methods, multicolumn partitioning is not supported for list partitioning. If a table is partitioned by list, the partitioning key can consist only of a single column of the table. Otherwise all columns that can be partitioned by the range or hash methods can be partitioned by the list partitioning method.

List Partitioning Example
CREATE TABLE Sales_List
(salesman_id NUMBER(5),
salesman_name VARCHAR2(30),
sales_state VARCHAR2(20),
sales_amount NUMBER(10), sales_date DATE)
PARTITION BY LIST(sales_state)
(PARTITION sales_west VALUES(‘California’, ‘Hawaii’),
PARTITION sales_east VALUES (‘New York’, ‘Virginia’, ‘Florida’),
PARTITION sales_central VALUES(‘Texas’, ‘Illinois’)
PARTITION sales_other VALUES(DEFAULT)
)
A row is mapped to a partition by checking whether the value of the partitioning column for a row falls within the set of values that describes the partition. For example, the rows are inserted as follows:
• (10, ‘Jones’, ‘Hawaii’, 100, ’05-JAN-2010′) maps to partition sales_west
• (21, ‘Smith’, ‘Florida’, 150, ’15-JAN-2010′) maps to partition sales_east
• (32, ‘Lee’, ‘Colorado’, 130, ’21-JAN-2010′) does not map to any partition in the table

Jun 28
You would like to communicate with a 3rd-party application from your PL/SQL program, for example you want to run a UNIX command. Or perhaps you’d like to communicate directly with another Oracle session. Whatever your specific communication needs are, DBMS_PIPE is your solution. 

What is DBMS_PIPE? 

DBMS_PIPE is a package provided by Oracle that allows two or more sessions in the same instance to communicate.  

The DBMS_PIPE package provides a non-secure mechanism for inter-session messaging. It is considered non-secure because messages can be lost from the pipe if the instance crashes or is shutdown before they are processed. Advanced Queues are arguably a better mechanism when secure messaging and greater flexibility are required.. 

Types: 

There are two types of pipes 

Implicit Pipes- These are created automatically when a message is sent with an unknown pipe name using the SEND_MESSAGE function. Implicit pipes disappear when they are empty. 

Explicit Pipes- These are created using the CREATE_PIPE function. Explicit created pipes must be removed using the REMOVE_PIPE function. 

Security: 

Depending upon your security requirements, you may choose to use either a public or a private pipe. 

Public Pipes- You may create a public pipe either implicitly or explicitly. For implicit public pipes, the pipe is automatically created when it is referenced for the first time, and it disappears when it no longer contains data. Because the pipe descriptor is stored in the SGA, there is some space usage overhead until the empty pipe is aged out of the cache. 

 You can create an explicit public pipe by calling the CREATE_PIPE function with the private flag set to FALSE. You must deallocate explicitly-created pipes by calling the REMOVE_PIPE function. 

The domain of a public pipe is the schema in which it was created, either explicitly or implicitly. 

Private Pipes- You explicitly create a private pipe by calling the CREATE_PIPE  function. Once created, the private pipe persists in shared memory until you explicitly deallocate it by calling the REMOVE_PIPE  function. A private pipe is also deallocated when the database instance is shut down. 

You cannot create a private pipe if an implicit pipe exists in memory and has the same name as the private pipe you are trying to create. In this case, CREATE_PIPE returns an error. 

Access to a private pipe is restricted to: 

  • Sessions running under the same userid as the creator of the pipe
  • Stored subprograms executing in the same userid privilege domain as the pipe creator
  • Users connected as SYSDBA or INTERNAL

An attempt by any other user to send or receive messages on the pipe, or to remove the pipe, results in an immediate error. Any attempt by another user to create a pipe with the same name also causes an error. 

In short we can say that oracle pipes are similar in concept to the pipes used in UNIX, but Oracle pipes are not implemented using the operating system pipe mechanisms. It is called a pipe because it connects two (or more) sessions, and messages are queued up inside, just like a pipe. Each session can take the next received item out of a pipe, or insert the next item to send. Anybody (with access) can insert or remove something from the pipe, in any order. Messages can only be removed and read once – two people can’t remove the same message from a pipe. 

In more real terms, these pipes are buffers in the system global area (the SGA). Messages are prepared for loading using PACK_MESSAGE, loaded into a pipe using SEND_MESSAGE, and read similarly (RECEIVE_MESSAGE then UNPACK_MESSAGE). 

Required grant to the user: 

GRANT EXECUTE ON SYS.DBMS_PIPE TO [user]  

The following example used the CREATE_PIPE function to create explicit public and private pipes. 

Public and Private Pipe

Let us see, does above code realy create pipes for us. To displays information about the pipes, we use V$DB_PIPES view. 

View Pipes

The following example uses REMOVE_PIPE function to remove the pipes, created previously. 

Remove Pipe

Let us see, does above code realy removes pipes that we created recently. 

Display Pipe

Writing and Reading Pipes

Each public pipe works asynchronously. Any number of schema users can write to a public pipe, as long as they have EXECUTE permission on the DBMS_PIPE package, and they know the name of the public pipe. However, once buffered information is read by one user, it is emptied from the buffer, and is not available for other readers of the same pipe. The sending session builds a message using one or more calls to the PACK_MESSAGE procedure. This procedure adds the message to the session’s local message buffer. The information in this buffer is sent by calling the SEND_MESSAGE function, designating the pipe name to be used to send the message. When SEND_MESSAGE is called, all messages that have been stacked in the local buffer are sent. 

 A process that wants to receive a message calls the RECEIVE_MESSAGE function, designating the pipe name from which to receive the message. The process then calls the UNPACK_MESSAGE procedure to access each of the items in the message. 

 For this test, open up two sessions as the SAME user on the SAME instance. Make sure your user has access to the DBMS_PIPE package. 

We are going to have the first instance create the pipe, send in an SQL command, and have the second instance retrieve that message and execute it. 

 Below is the step by step procedure to implement communication between two sessions 

 1) Create a Pipe: Depending upon the need create pubic of private pipe. For this we use DBMS_PIPE.CREATE_PIPE Function. 

Create Pipe

 2) Checking the Pipes in the Database, by using v$db_pipes view. 

View Pipe

3) Sending message through session #1. For this we use PACK_MESSAGE and SEND_MESSAGE functions of the DBMS_PIPE package. 

Send Message

4) Receiving message in session #2, For this we use Receive_Message and UNPACK_Message functions of DBMS_PIPE package. 

Receive Message

Pipe Uses

The pipe functionality has several potential applications. Some of these are mentioned below: 

  • External service interface: You can communicate with user-written services that are external to the RDBMS. This can be done in a (effectively) multi-threaded manner, so that several instances of the service are executing simultaneously. Additionally, the services are available asynchronously. The requestor of the service does not need to block a waiting reply. The requestor can check (with or without timeout) at a later time. The service can be written in any of the 3GL languages that Oracle supports.
  • Independent transactions: The pipe can communicate to a separate session which can perform an operation in an independent transaction (such as logging an attempted security violation detected by a trigger).
  • Alerters (non-transactional): You can post another process without requiring the waiting process to poll. If an “after-row” or “after-statement” trigger were to alert an application, then the application would treat this alert as an indication that the data probably changed. The application would then read the data to get the current value. Because this is an “after” trigger, the application would want to do a “select for update” to make sure it read the correct data.
  • Debugging: Triggers and stored procedures can send debugging information to a pipe. Another session can keep reading out of the pipe and display it on the screen or write it to a file.
  • Concentrator: This is useful for multiplexing large numbers of users over a fewer number of network connections, or improving performance by concentrating several user-transactions into one DBMS transaction.
preload preload preload