Saturday Nov 29, 2008

OpenSSO Complex Deployment

This series of videos are video captures of the course below. There is no sound for now, but this will be added at a later date.


From http://slslabs.sun.com/course/wspl-am-3508-d
Deploying OpenSSO servers in a simple environment is trivially easy. But throw secure sockets layer (SSL), load balancers, multiple servers, session failover, and Policy Agents into the mix, and deployment becomes a little more complex.


The OpenSSO Deployment course - a series of five downloadable, self-paced labs - takes you through a complex OpenSSO deployment. You deploy two Apache Tomcat servers, SSL-enable them, install a software load balancer, install OpenSSO into the environment, and configure OpenSSO for session failover. Then you install an example web server and an example application server, and install Policy Agent software to see how OpenSSO protects web sites and JavaTM 2 Platform, Enterprise Edition (J2EETM) applications.


This course uses OpenSSO Build 4.5, which provides identical functionality to OpenSSO Express Build 5. Other deployment components include Apache Tomcat version 6.0.14, Sun Java System Web Server version 7.0, and GlassFishTM application server version 2.



OpenSSO Complex Deployment Lab 1 Exercise 1



OpenSSO Complex Deployment Lab 1 Exercise 2



OpenSSO Complex Deployment Lab 1 Exercise 3



Wednesday Oct 29, 2008

WS-Federation is adopting SAML v2 metadata

WS-Federation is adopting SAML 2.0 metadata when it releases WS-Federation 1.2. OpenSSO uses WS-Fed 1.1 metadata which is now deprecated. Expect to see an openSSO release soon that will adopt WS-Fed 1.2

http://identity-des.com/2008/10/28/harmonized-federation-metadata-for-ws-federation-and-saml

Sunday Oct 12, 2008

XACML - Declarative Access Control

Web applications need access control. I'm not gonna justify that fact. All web applications have the ability where you can restrict access to the resources that reside on it by simply modifying the deployment descriptors (web.xml). This method is called declarative security or declarative access control. Well, but does this really suffice ?


Well, say hello to XACML. XACML stands for eXtensible Access Control Markup Language.

It is a declarative access control policy language implemented in XML and a processing model, describing how to interpret the policies.

If you had followed what Daniel Raskins had said from a long time ago, about supporting XACML, well, here it is. OpenSSO now has XACML support.
Support for XACML allows our customers to share access control policies across corporate boundaries and offers more dynamic standards-based tools for creating federated mashups. As a result, our customers can continue to expand their business reach while using open-standards to enforce security decisions and minimize security risk.

The OpenSSO codebase also has a XACML client sample which you could download, compile and run in a few clicks.


Please Note: This is NOT sunxacml. sunxacml is implementation of XACML 2.0 specifications from sun labs. This does not have support for SAML2.0 profile of XACML 2.0 and is not part of OpenSSO.


OpenSSO XACML implements SAML2.0 Profile of XACML2.0 - supporting XACMLAuthzDecisionQuery and XACMLAuthzDecisionStatement. PEP makes XAML2.0/SAML2.0/SOAP request to PDP and gets response. The OpenSSO XACML client sample is a remote client library that could be used by an application to make XACML calls to PDP.


The returned XACMLAuthzDecisionStatement has XACML Response, Result, Decision and so forth. The OpenSSO XACML implementation leverages SAML2.0 capability of OpenSSO to manage SAML2 metadata of PDP and PEP and exchange SAML messages.


Here's a simple 5 step guide to running the XACML client and testing it with opensso.

  • get the OpenSSO.zip, extract and get the opensso-client.zip under samples directory

  • extract the opensso-client.zip, and goto "sdk" subdirectory

  • follow the README file to setup the samples

  • follow the instruction in scripts/run-xacml-client-sample.sh to setup the XACML.

I hope this post has been helpful. Cheers and enjoy building applications that use XACML !! interoperability rocks!!

Thursday Jan 17, 2008

AM SSO FILTER

Back to normal programming. No more infocard stuff here. With a typical Access Manager deployment atop a webserver or appserver, there are many instances where apart from the Access Manager services deployed, one may deploy other applications on the same server instance and may need to "protect" them. The right way of going about it is to deploy a policy agent on the same server instance. I noticed that in some cases folks choose not to deploy an agent but "embed" code in every page of their webapp to check for the validity of the SSOToken issues by AM and enable access to thise pages that they need "protected". Well, if all one needs is to protect a few URI's that reside on the same server instance as AM, one could also use a Servlet Filter to do the same without having to embed code in every page of their application to check for it. This is a simple SSO only method and not a replacement for a policy agent. Here's what one needs to do to enable this. Declare the [filter] element in your web application deployment descriptor. For Sun's Webserver it would be the default-web.xml file. Map the filter to a servlet by defining a <filter-mapping> element in the deployment descriptor. This element maps a filter name to a servlet by name or by URL pattern. Add the URL's you would like to "protect" to the url-pattern tag element.
Now compile the attached code, build a jar file and add it to your servers classpath.
for some reason I just cannot post code on this blog. No matter what I try, the code gets converted over to HTML. I did follow Pat's advise, but that didnt help. So I'm uploading the NNAgent.java file and providing you a link to download it instead of posting code as inline text
Restart your webserver.
  • Try accessing the "protected" URL without authentication.
  • Try accessing the "protected" URL with authentication.
You'd see the difference... NOTE: This is NOT a replacement for a Policy Agent. This is just an FYI/example of how one could achieve SSO only using a Filter.

Open Source Identity Management

OK... here's my prediction for the new year and the oncoming... Identity Management would be the CORE for WEB 2.0-The next generation Web. Having said that I thought that it would be good to list out a few open source Identity Management products that are out there that one would need to keep a keen eye on... PS: Do feel free to add to this list by leaving your comments.
  • Sun Interoperability Prototype for Liberty : Interoperability Prototype for Liberty is the first open-source implementation of the Liberty Alliance Version 1.0 specification based on Java technology. IPL consists of sample Java source code libraries, implementing the Liberty version 1.0 specification, and is not designed for commercial deployment. IPL is licensed as open source under the Sun Microsystems Open Source License.
  • SourceID : Open Source Federated Identity Management Liberty Alliance, SAML, and WS-Federation. Royalty free commercial use if used on fewer than 100 computers per company
  • Shibboleth : Shibboleth is developing architectures, policy structures, practical technologies, and an open source implementation to support inter-institutional sharing of web resources subject to access controls. Key concepts within Shibboleth include: Federated Administration, Access Control Based On Attributes, Active Management of Privacy and used OpenSAML.
  • OpenSAML : OpenSAML is a set of open source Java and C++ libraries that are fully consistent with the SAML 1.0 and 1.1 CR specifications.
  • Yale CAS : The Central Authentication Server (CAS) is designed as a standalone web application. It is currently implemented as several Java servlets and runs through a HTTPS server.
  • Atlassian Seraph : Seraph is a very simple, pluggable J2EE web application security framework.
  • OpenSPML : The toolkit offers an easy-to-use interface for configuring, issuing and interpreting standards-compliant provisioning requests across diverse identity infrastructures.
  • Novell Nsure UDDI Server : Nsure is a UDDI 2.0 registry built on Directory Services technology. It offers a secure access to the registry contents (authentication and authorization), unified account management, and distribution of the registry by leveraging Directory Services. It works with any LDAP(V3) based directory backend.
  • OpenPrivacy : A reference implementation of the Reputation Management Framework (RMF). OpenPrivacy's core project is designed to ease the process of creating community with reputation enhanced pseudonymous entities. The RMF is primarily a set of four interfaces: Nym Manager, Communications Manager, Storage Manager and Reputation Calculation Engine (RCE).
  • NSF Middleware Initiative : NMI-EDIT: Identity and Access Management for Collaborative Applications.
  • jSai : jSai (pronounced "Jay-Say") is iPOV's home grown Servlet Authentication Implementation. jSai is implemented completely using J2SE + Servlet technology; no J2EE "Application Server" needed. jSai supports basic JDBC and XML backed user stores, as well as an LDAP user store. jSai provides developers with the application level security they want and need for small and medium size web applications; avoiding the complex setup in other security implementations that are aimed at large "enterprise" applications.
  • Acegi Security System for Spring : Comprehensive security services for The Spring Framework.
  • Gabriel : Gabriel is a security framework for Java. By using access control lists and permissions, Gabriel enables components to check access to actions. On top of that Gabriel protects methods like EJB does but without the overhead. It distinguishes itself from other frameworks by the ease of use with a small API and by mapping method access to permissions instead of persons. This way the same permissions can be used to protect method access and to check which GUI elements to show based on user permissions.
  • JOSSO : JOSSO, or Java Open Single Sign-On, is an open source J2EE-based SSO infrastructure aimed to provide a solution for centralized platform neutral user authentication. The Pluggable framework allows to implement and combine multiple authentication schemes with credential stores.
  • Kasai : The goal of Kasai is to provide a simple-to-use-yet-powerful security environment for multi-user applications. Unlike JAAS, Kasai provides a much higher security abstraction. Additionally, Kasai includes a very powerful and performing auditing system that records all users activity on a relational database.
  • JPAM : JPAM is a Java-PAM bridge. PAM, or Pluggable Authentication Modules, is a standard security architecture used on Unix, Linux and Mac OS X systems. JPAM permits the use of PAM authentication facilities by Java applications running on those platforms.
  • CAS Generic Handler : CAS Generic Handler is a plugin giving CAS (Central Authentication Service) the ability to authenticate users with different methods (LDAP, database, files, NIS, ...).
  • SunXACML : This project provides complete support for all the mandatory features of XACML as well as a number of optional features. Specifically, there is full support for parsing both policy and request/response documents, determining applicability of policies, and evaluating requests against policies. All of the standard attribute types, functions, and combining algorithms are supported, and there are APIs for adding new functionality as needed. There are also APIs for writing new retrieval mechanisms used for finding things like policies and attributes.
  • Shaj : Shaj (Simple Host Authentication for Java) is a simple library that allows your Java app to verify users with the underlying operating system. Shaj also allows you to check group membership. Shaj is not a competitor for full featured authentication API's but rather a complimentary way to piggyback on system accounts on any platforms. Shaj is used in FishEye for local account authentication, hence it is in use on most flavours of Windows and \*NIX.
  • Open Web SSO : The Open Web SSO project provides core identity services to facilitate the implementation of transparent single sign on as an infrastructure security component. The goal of Open Web SSO project is to provide an extensible implementation of identity services infrastructure that will facilitate single sign on for web applications hosted on web and application serversThis project is based on the code base of Sun Java(tm) System Access Manager product.
  • Cosign : Support Global Logout by visiting a link Support GSSAPI authentication Written in C and support MS ISAPI (IIS), Apache 1.3/2.0, Servlet and Java/J2EE
Links Courtesy: Carlos E. Perez
UPDATE: another comprehensive list at http://safehaus.org/map/nov05.html. Link Courtesy : Shekhar Jha UPDATE 2: Shekar Jha has also compiled a very nice list of Identity & Access Management vendors. boy!! how could I have missed that one ?

DE-Federated Identity Access (DEAF)

Identity Management, and Identity Federation has been the buzzword in this space for a while now. According to the definition of "Federated Identity" on wikipedia, it has two general meanings:
  • The virtual reunion, or assembled identity of a person's user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of the common token, usually the user name.
  • The process of a user's authentication across multiple IT systems or even organisations.
now, this is great when the Legal Entity has a unique "identity" on each of the disparate systems. But when the Legal Entity who has a identity on a system is provided access to a partner site or system, there is absolutely no "Federation" possible if the Legal Entity has no identity on the partner site or system. I was involved in a brainstorming session related to shibboleth with a few technical folks from a university. What came up was the need to allow students from one university to access resources from another university. The folks I was interacting with were "sold" on the idea of federation, but lacked complete understanding of how federation really worked. Here were my concerns:
  • The user needed to have a unique identity on either systems.
  • The user needs to explicitly "federate" his identity. (If he does have a unique identity on each system)
  • If the users identity gets stolen, well, we have a much bigger issue.
(I thought) What the university really needed was implicit Federation. Whereby when a user who has authenticated himself at one university, when provided access to resources in another, should be granted access even thought the user does not have a unique identity at the other. Here's an example:
  1. University1 and University2 belong to a "defined" Circle of Trust.
  2. Student at University1 authenticates at University1.
  3. Student tries to access resources at University2.
  4. University2 Requests University1 to assert the validity of the user session.
  5. University1 Asserts that the user is "A" authenticated user, but does not actually reveal the users "handle" or "identity" in any form
  6. University2 grants the user access by just knowing that the user is a "authenticated" user at University1, without even knowing who the user actually is. (University2 provides just generic content to the user)
  7. User tries to personalize his "content" or University2 needs to provide the User "specific" content based on role the student has at University1
    • University2 would need to prompt the user for "permissions" to derive his "role" from UnIversity1
    • User grants permissions by using a digital signature of some sort.
    • University2 uses that digital signature to request University1 for the Users roles
    • University1 verifies that the digital signature matches that of the Authenticated User and grants University2 the users roles and/or "identity/alias".
    • University2 provisions a local "identity/alias" and associates it with the "role" as asserted by University1
  8. University2 can now allow the user to "personalize "content" or provide the user "content" as necessary.
I believe that with this aproach, even though a student has no "identity" on one system or university (University2 in the example I used) he/She still gets to experience the "magic" of "federation". On second thoughts, If I apply this to the examples widely used in "federation", where a airliner and a car rental company are in a circle of trust, well, I am sure that the car rental company would love to receive a new unidentified user from a "partner airline" and dynamically provision the user and sell him a product !!! it's all about making money in the bargain right ? or is it just making the user experience more enjoyable and easy ? I believe that we'd be kidding ourselves if we say that it's ONLY about "user experience" Now: The user providing his/her "digital signature" to the car rental company is another story altogether.. ;-) Comment Away Please... (Comments are active for only 30 days from the date of this posting) UPDATE : Please Read Pat Patterson's response by Clicking Here or by following the link in the 1st Comment/Trackback below.

OpenSSO is Open For Business

Pat Patterson just made me aware that the architecture draft and usecase documents for the opensso project have been published.
The objective of this document is to provide brief and precise information relevant to the high-level architectural goals of core identity services for the web platform. The examples provided in this document are based on the general understanding of web application interactions where the end user interacts with target systems using a traditional web browsing application and follows hyperlinks or other similar constructs. Familiarity with operational aspects of web applications is a prerequisite to understanding the concepts and ideas discussed within this document.
Rush Over, Read the docs as soon as you can, I have been awaiting this for a while now. The part I liked best was section 2.3.2 on Security and Confidentiality. OpenSSO has it's initial miniscule set of limitations though, especially when dealing with "Cross Domains". But hey, the project is at it's infancy right now. I bet Cross Domain SSO (OpenCDsso) would be introduce as participation increases. It's Open Source and it's our participation that makes a product attain it's peak in service provisioning. So go ahead lend a hand. I would love to see opensso handling tickets in addition to cookies/token validation. Hey maybe we could start a opensso branch for extensions. PS: Thanks, Arvind for putting this together so fast.
About

for everything on Identity, JCAPS, SOA, WebServices, Security, Single Signon, Federation, Provisioning, Virtualization, Optimization, Debugging, Workflows, Compliance, MySQL and more... WAY MORE....

[this is a group blog]

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today