1. Security and reliability in distributed applications www.hndit.com

2. Security in Multitiered Applications The Java EE security environment enables security constraints to be defined at deploy time. Java EE applications are portable to many security implementations. The Java EE provides – Standard declarative access control rules that are defined by the developer and interpreted when the application is deployed on the server. – Standard login mechanism. www.hndit.com

3. Security in Multitiered Applications J2EE and web services applications are made up of components that can be deployed into different containers. These components are used to build a multitier enterprise application. Security for components is provided by their containers. A container provides two kinds of security: – declarative and – Programmatic security. www.hndit.com

4. Declarative security Declarative security expresses an application’s security structure, including security roles, access control, and authentication requirements, in a form external to the application (in a deployment descriptor) www.hndit.com

5. Programmatic security Programmatic security is embedded in an application and is used to make security decisions. Programmatic security is useful when declarative security alone is not sufficient to express the security model of an application. www.hndit.com

6. Security Threats www.hndit.com

7. Security concepts/ mechanisms www.hndit.com

8. Security Technologies www.hndit.com

9. Primary aspects of security addressed by distributed computing Identification Authentication Authorization Integrity Confidentiality Non-repudiation www.hndit.com

11. Realms, Users, Groups, and Roles A J2EE user is similar to an operating system user. Typically, both types of users represent people. The J2EE server’s authentication service includes and interacts with the following components: Realm: A collection of users and groups that are controlled by the same authentication policy. User: An individual (or application program) identity that has been defined in the Application Server. Users can be associated with a group. Group: A set of authenticated users, classified by common traits, defined in the Application Server. Role: An abstract name for the permission to access a particular set of resources in an application. A role can be compared to a key that can open a lock. Many people might have a copy of the key. The lock doesn’t care who you are, only that you have the right key. www.hndit.com

12. Securing Web Applications Web-Tier Security www.hndit.com

13. Web-Tier Security Security in a web application is configured in the web application deployment descriptor using deploytool. When the settings are entered in deploytool, they are saved to the deployment descriptor contained in theWAR. To view the generated deployment descriptor, select Tools→Descriptor Viewer→Descriptor Viewer from the deploytool menu. After a WAR is created, select the Security tabbed pane to configure its security elements. www.hndit.com

14. Configure web security (BIG Picture)Configure web security (BIG Picture) JBoss Application Server server.xml JBoss Webserver web.xml jboss- web.xml Login- config.xml Security Data store Connector Web Application Security domain defines points to definespoints to www.hndit.com

15. Primary Configuration FilesPrimary Configuration Files www.hndit.com

16. Configuring security in web.xmlConfiguring security in web.xml Web-app security-constraint User-data-constraint auth-constraint web-resource-collectionurl-pattern role-name transport -guarantee login-config security-role 0..* 1..* 0..1 0..* 0..1 1 auth-method Role-name 0..1 1 0..* www.hndit.com

17. Security constraint A security constraint determines who is authorized to access a web resource collection, which is a list of URL patterns and HTTP methods that describe a set of resources to be protected. Security constraints are defined using an application deployment tool, such as deploytool,. www.hndit.com

18. web.xml - Exampleweb.xml - Example www.hndit.com

19. jboss-web.xml - Example www.hndit.com

20. Authenticating strategiesAuthenticating strategies

21. Form Based AuthenticationForm Based Authentication User Web Container Security Framework Security data store Show account Summary Is page secured? Yes Display login page Provide username/password Display account summary Are login/roles valid? Yes Get password/roles for user www.hndit.com

22. Authorizing UsersAuthorizing Users Use * to all access to any authenticated user www.hndit.com

23. Encrypting web communicationEncrypting web communication Create or obtain a digital certificate for your application server. Make sure that the certificate is stored in a keystore. Enable the secure HTTP connector. Point the secure HTTP connector to your keystore. www.hndit.com

24. Default security domainDefault security domain No security domain defined in the (web app) jboss-web.xml, but have defined security for various components in web.xml file JBoss defaults to the default security domain configured in the server/xxx/deployers/jbossweb.deployer/META-INF/war-deployers-jboss- beans.xml This property points to the security domain jboss-web-policy, which is defined in the server/xxx/deploy/security/security-policies-beans.xml file. This security domain is an extension of the other security domain defined in the server/xxx/conf/loginconfig. xml file www.hndit.com

25. Service-oriented applications’ Security Service-oriented applications need to be outfitted to handle many of the traditional security demands of protecting information and ensuring that access to logic is only granted to those permitted. www.hndit.com

26. Security specifications that may be used as part of SOA WS-Security WS-SecurityPolicy WS-Trust WS-SecureConversation WS-Federation Extensible Access Control Markup Language (XACML) Extensible Rights Markup Language (XrML) XML Key Management (XKMS) XML-Signature XML-Encryption Security Assertion Markup Language (SAML).NET Passport Secure Sockets Layer (SSL) WS-I Basic Security Profile www.hndit.com

27. The SOAP messaging communications framework, upon which contemporary SOA is built, emphasizes particular aspects of security that need to be accommodated by a security framework designed specifically for Web services. A family of security extensions parented by the WS-Security specification comprise such a framework www.hndit.com

28. WS-SecurityPolicy WS-SecurityPolicy is a web services specification, created by IBM and 12 co-authors, that has become an OASIS standard as of version 1.2. It extends the fundamental security protocols specified by the WS-Security, WS-Trust and WS- SecureConversation by offering mechanisms to represent the capabilities and requirements of web services as policies. Security policy assertions are based on the WS-Polic framework. www.hndit.com

29. Identification, authentication, and authorization For a service requestor to access a secured service provider, it must first provide information that expresses its origin or owner. This is referred to as making a claim Claims are represented by identification information stored in the SOAP header. WS-Security establishes a standardized header block that stores this information, at which point it is referred to as a token. www.hndit.com

30. Identification, authentication, and authorization www.hndit.com

31. Authentication Authentication requires that a message being delivered to a recipient prove that the message is in fact from the sender that it claims to be. www.hndit.com

32. Authorization Once authenticated, the recipient of a message may need to determine what the requestor is allowed to do. This is called authorization www.hndit.com

33. Single sign-on Single sign-on technology allows a service requestor to be authenticated once and then have its security context information shared with other services that the requestor may then access without further authentication. There are three primary extensions that support the implementation of the single signon concept: – SAML (Security Assertion Markup Language) –.NET Passport – XACML (XMLAccess Control Markup Language) www.hndit.com

34. Transport-level security and message- level security in SOC The type of technology used to protect a message determines the extent to which the message remains protected while making its way through its message path. Secure Sockets Layer (SSL), for example, is a very popular means of securing the HTTP channel upon which requests and responses are transmitted. However, within a Web services- based communications framework, it can only protect a message during the transmission between service endpoints. Message-level confidentiality for an XML-based messaging format, such as SOAP, can be realized through the use of specifications that comprise the WS-Security framework. www.hndit.com