Milestone of the Project

wanderooswarrenΤεχνίτη Νοημοσύνη και Ρομποτική

21 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

77 εμφανίσεις


1

Milestone

of the Project


Title of Project: Research on
Apache Shrio security

Framework

Members:
R
achana

M
navale
, M
uralidharan

V
adivel
, Joon Ho Yang


1.

Goal

and Objective:


Recently JAVA developer mainly use
to
the security framework
to enforce the security of
products. Until now
,

the JAAS
was

the most popular security framework and now the Apache
SHRIO

comes out to cover the shortcoming of JAAS

and giving some beneficial aspect
s

for
developer
. Also
Acegi

security f
ramework has the security modules for authentication and
access
-
control framework.
Even if the there are several java security framework, people
hasn’t known which security frameworks
are suitable for their product. Choosing the best
framework during designing the architecture is very important.
In this research, we will come
up with the shortcoming and benefits of each security framework and
offer users valuable
information when they f
ind out the security framework with demo program.



2.

Description of the problem and motivation

It Would be difficult for us to do a comprehensive comparison of the three framework in the
limited time span. Instead we chose to do an analysis of the apache sh
iro framework because
of its advantages over the other platforms.

The main motivation for doing analysis on apache shiro is:



The easiest to understand Java Security API anywhere. Class and Interface names are
intuitive and
make sense
. Anything is pluggable

but good defaults exist for everything.



Support authentication ('logins') across one or more pluggable data sources (LDAP,
JDBC, Kerberos, ActiveDirectory, etc).



Perform authorization ('access control') based on roles or fine
-
grained permissions, also
usi
ng pluggable data sources.



First
-
class caching support for enhanced application performance.



Built
-
in POJO
-
based Enterprise Session Management. Use in both web and non
-
web
environments or in any environment where Single Sign On (SSO) or clustered or
distri
buted sessions are desired.



Heterogeneous

client session access. You are no longer forced to use only the
HttpSession

or Stateful Session Beans, which often unnecessarily tied applications to
specific environments. Flash applets, C# applications, Java Web
Start, and Web
Applications, etc. can now all share session state regardless of deployment environment.



Simple Single Sign
-
On (SSO) support piggybacking the above Enterprise Session
Management. If sessions are federated across multiple applications, the us
er's

2

authentication state can be shared too. Log in once to any application and the others all
recognize that log
-
in.



Secure data with the easiest possible Cryptography APIs available, giving you power and
simplicity beyond what Java provides by default
for ciphers and hashes.



An incredibly robust yet
low
-
configuration

web framework that can secure any url or
resource, automatically handle logins and logouts, perform Remember Me services, and
more.



Extremely low number of required dependencies. Standalone

configuration requires only
slf4j
-
api.jar

and one of slf4j's binding .jars. Web configuration additionally requires
commons
-
beanutils
-
core.jar
. Feature
-
based dependencies (Ehcache caching, Quartz
-
based Session validation, Spring dependency injection, etc.
) can be added when needed.

3.

Proposed approach



Understand the Overall architecture of the apache Shiro framework.

i.

Analyze the main API’s like
Subject, SecurityManager, Authenticator,
Authentication Strategy, Authorizer, SessionManager, SessionDAO,
CacheManager, Cryptography, Realms



Analyze the Design related to :

1.

Authentication

2.

Authorization

3.

Session Management

4.

Cache Management

5.

Realm

coordination

6.

Event propagation

7.

"Remember Me" Services

8.

Subject creation

9.

Logout

and more.



Create a Si
mple Demo using apache shiro to
.


4.

Detailed literature search

Shiro is a framework implemented in the Java language that provides both authentication and
authorization in an easy
-
to
-
use API. By using Shiro, you can provide security for your
application with
out writing all of the code from the beginning.



The
Apache Shiro
architecture

overview

Shiro's architecture has 3 primary concepts: the

Subject,

S
ecurityManager

and

Realms
.


3

Subject
:
T
he

Subject

is essentially a security specific 'view' of the the

currently
executing user. Whereas the word 'User' often implies a human being, Subjectcan be a
person, but it could also represent a 3rd
-
party service, daemon account, cron job, or
anything similar
-

basically anything that is currently interacting with t
he software.

Subject

instances are all bound to (and require) a

SecurityManager. When you interact
with a

Subject, those interactions translate to subject
-
specific interactions with the

SecurityManager.

SecurityManager
:
The

SecurityManager

is the heart of
Shiro’s architecture and acts as a
sort of 'umbrella’ object that coordinates its internal security components that together
form an object graph. However, once the SecurityManager and its internal object graph is
configured for an application, it is usual
ly left alone and application developers spend
almost all of their time with the

Subject

API.

Realms
:
Realms act as the ‘bridge’ or ‘connector’ between Shiro and your application’s
security data. When it comes time to actually

interact with security
-
related data like user
accounts to perform authentication (login) and authorization (access control), Shiro looks
up many of these things from one or more Realms configured for an application.


In this sense a Realm is essentially a
security
-
specific

DAO
: it encapsulates connection
details for data sources and makes the associated data available to Shiro as needed. When
configuring Shiro, you must specify at least one Rea
lm to use for authentication and/or
authorization. The

SecurityManager

may be configured with multiple Realms, but at least
one is required.


Shiro

provides out
-
of
-
the
-
box Realms to connect to a number of security data sources
(aka directories) such as LDAP, relational databases (JDBC), text configuration sources
like INI and properties files, and more. You can plug
-
in your own Realm implementations
to represent custom data sources if the default Realms do not meet your needs.


Like other internal components, the Shiro

SecurityManager

manages how Realms are
used to acquire security and identity data to be represented as

Subject

instances.





Detailed
Architecture

The following diagram shows Shiro's core architectural concepts followed by short
summaries of each:


4





Subject

(
org.apache.shiro.subject.Subject
)

A security
-
specific 'view' of the entity (user, 3rd
-
party service, cron job, etc) currently
interacting with the software.



SecurityManager

(
org.apache.shiro.mgt.SecurityManager
)

As mentioned above, the

SecurityManager

is the heart of Shiro's architecture. It is mostly
an 'umbrella' object that coordinates its managed components to ensure they work
smoothly together. It also manages Shiro's
view of every application user, so it knows
how to perform security operations per user.



Authenticator

(
org.apache.shiro.authc.Authenticator
)

The

Authenticator

is the component that is responsible for executing and reacting to
authentication (log
-
in) attempts by users. When a user tries to log
-
in, that logic is
executed by the

Authenticator. The

Authenticator

knows how to coordinate with one or
more

Realms

that store relevant user/account information. The data obtained from these

Realms

is used to verify the user's identity to guarantee the user really is who they say
they are.



Authentication

Strategy

(
org.apache.shiro.authc.pam.AuthenticationStrategy
)

If more than one

Realm

is configured, the

AuthenticationStrategy

will coordinate the
Re
alms to determine the conditions under which an authentication attempt succeeds or
fails
.


Authorizer

(
org.apache.shiro.authz.Authorizer
)

The

Authorizer

is

the component responsible determining users' access control in the
application. It is the mechanism that ultimately says if a user is allowed to do something
or not. Like the

Authenticator, the

Authorizer

also knows how to coordinate with multiple
back
-
en
d data sources to access role and permission information. TheAuthorizer

uses this
information to determine exactly if a user is allowed to perform a given action.


SessionManager

(
org.apache.shiro.session.mgt.SessionManager
)

The

SessionManager

knows how to create and manage user

sess
ion

ifecycles

to provide a
robust Session experience for users in all environments. This is a unique feature in the
world of security frameworks
-

Shiro has the ability to natively manage user Sessions in
any environment, even if there is no Web/Servlet or EJB containe
r available. By default,
Shiro will use an existing session mechanism if available, (e.g. Servlet Container), but if
there isn't one, such as in a standalone application or non
-
web environment, it will use its

5

built
-
in enterprise session management to offe
r the same programming experience. The

SessionDAO

exists to allow any datasource to be used to persist sessions.


SessionDAO

(
org.apache.shiro.sessi
on.mgt.eis.SessionDAO
)

The

SessionDAO

performs

Session

persistence (CRUD) operations on behalf of the

SessionManager. This allows any data store to be plugged in to the Session Management
infrastructure.


CacheManager

(
org.apache.shiro.cache.CacheManager
)

The

CacheManager

creates and manages

Cache

instance lifecycles used by other Shiro
components. Because Shiro can ac
cess many back
-
end data sources for authentication,
authorization and session management, caching has always been a first
-
class architectural
feature in the framework to improve performance while using these data sources. Any of
the modern open
-
source and/
or enterprise caching products can be plugged in to Shiro to
provide a fast and efficient user
-
experience.


Cryptography

(
org.apache.shiro.crypto.*
)

Cryptography is a natural addition to an enterprise security framework. Shiro's

crypto

package contains easy
-
to
-
use and understand representations of crytographic Ciphers,
Hashes (aka digests) and different codec implementations. All of the classes in this

package are carefully designed to be very easy to use and easy to understand. Anyone
who has used Java's native cryptography support knows it can be a challenging animal to
tame. Shiro's crypto APIs simplify the complicated Java mechanisms and make
crypto
graphy easy to use for normal mortal human beings.


Realms

(
org.apache.shiro.realm.Realm
)

As mentioned above, Realms act as the ‘bridge’ or ‘connector’ between
Shiro and your
application’s security data. When it comes time to actually interact with security
-
related
data like user accounts to perform authentication (login) and authorization (access
control), Shiro looks up many of these things from one or more Rea
lms configured for an
application. You can configure as many

Realmsas you need (usually one per data source)
and Shiro will coordinate with them as necessary for both authentication and
authorization.



5.

Preliminary result



Compare with popular frameworks.
(JAAS &
ACEGI

& Shiro)

1.

JAAS (JavaTM Authentication and Authorization Service)

The JavaTM Authentication and Authorization Service (JAAS) was introduced as an
optional package (extension) to the JavaTM2 SDK, Standard Edition (J2SDK), v 1.3.
JAAS has now bee
n integrated into the J2SDK, v 1.4.

Every application server vendor is
free to implement container security differently nor are they required to use JAAS. This
leads to portability and user management constraints. Furthermore, it still does not
approach se
curity in the manner as described above
-

as an aspect.



JAAS can be used for two purposes:

For authentication of users, to reliably and securely determine who is currently executing
Java code, regardless of whether the code is running as an application, an applet, a bean,

6

or a servlet
.
For authorization of users to ensure they have the access co
ntrol rights
(permissions) required to do the actions performed.

The JAAS
-
related core classes and interfaces can be broken into 3 categories: Common,
Authentication, and Authorization.



Common Classes
: The key JAAS class is
javax.security.auth
.Subject
, which represents a
grouping of related information for a single entity such as a person. It encompasses the
entity's
Principals
, public

credentials, and private credentials.

Subject
,
Principal
,
Credential

(actually, any Object)

Subject: The JAAS framework defines the term subject to represent the source of a
request.
A subject may be any entity, such as a person or a service. Once the subject is
authenticated,

a

javax.security.auth.Subject

is populated with associated

identities, or
Principals
. A Subject may have many

Principals.

Principal: Principals represent Subject
identities, and must

implement

the
java.security.Principal

and

java.io.Serializable

interfaces.


Authentication Classes
:
To authenticate a subject (user or service), the following steps
are performed:An application instantiates a LoginContext.

The LoginContext
consults a
Configuration

to load all of the LoginModules configured
for that application.

The application invokes the LoginContext's login method.

The

login method invokes all of the loaded LoginModules. Each LoginModule attempts
to authenticate the subject. Upon success, LoginModules associate relevant Principals
and credentials with a Subject object that represents the subject being authenticated.

The

LoginContext returns the authentication status to the application.

If authentication succeeded, the application retrieves the Subject from the oginContext.

LoginContext
,
LoginModule
,
CallbackHandler
,
Callback

The
javax.security.auth.login.LoginContext

class provides the basic methods used to
authenticate subjects, and provides a way to develop an application independent of the
underlying authentication technology
.
The
LoginModule

interface gives developers the
ability to implement different kinds of authentication technologies that can be plugged in
under an application
.
Authorization Classes

Policy
,
AuthPermission
,
PrivateCredentialPermission
.
The
javax.security.auth.AuthPermission

class encapsulates
the basic permissions required for JAAS. An AuthPermission contains a name (also
referred to as a "target name") but n
o actions list.

References:
http://docs.oracle.com/javase/1.4.2/docs/guide/security/jaas/JAASRefGuide.html



2.

ACEGI Security Framework

Enter the Acegi

Security framework, an open source security framework designed for
Spring.

Acegi Security System uses security filters to provide authentication and authorization
services to enterprise applications. The framework offers several types of filters that you
can configure according to your application requirements. You will learn about the
various types of security filters

later in the article; for the moment, just

note that you can
configure Acegi's security filters for the following tasks:


Architecture and components

Acegi Security System consists of four main types of component: filters, managers,
providers, and handlers.

Filters
.
These most high
-
level components provide common
security services like authentication processing, session handling, and logout.Managers
.


7

Filters are only a high
-
level abstraction of security
-
related functionality: managers and
providers are used to actuall
y implement authentication processing and logout services.
Managers manage lower level security services offered by different providers.

Providers
.
A variety of providers are available to communicate with different types of
data storage services, such as d
irectory services, relational databases, or simple in
-
memory objects. This means you can store your user base and access control policies in
any of these data storage services and Acegi's managers will select appropriate providers
at run time.

Acegi's logo
ut filter uses two handlers to sign out an HTTP client. One handler
invalidates a user's HTTP session and another handler destroys the user's cookie. Having
multiple handlers provides flexibility while configuring Acegi to work according to your
applicatio
n requirements. You can select the handlers of your choice to execute the steps
required to secure your application.


R
eference:

http://www.javalobby.org/articles/acegisecurity/part
1.jsp

http://www.ibm.com/developerworks/java/library/j
-
acegi1/index.html

API:
http://www.jarvana.com/jarvana/view/org/acegisecurity/acegi
-
security/1.0.2/acegi
-
security
-
1.0.2
-
javadoc.jar!/index.html


3.

Apache SHIRO

Shiro targets what the Shiro

development team calls "the four cornerstones of application
security"
-

Authentication, Authorization, Session Management, and Cryptography:

Authentication:

Sometimes referred to as 'login', this is the act of proving a user is who they say they are.

Aut
horization:

The process of access control, i.e. determining 'who' has access to 'what'.

Session Management:

Managing user
-
specific sessions, even in non
-
web or EJB applications.

Cryptography:

Keeping data secure using cryptographic algorithms while still b
eing easy to use.


Reference:
API:
http://shiro.apache.org/static/current/apidocs/


6.

T
ime plan




8