Posts Tagged ‘SSO’

« Older Entries

Setting the Windows Security Context with SiteMinder

Thursday, September 8th, 2011

Note: Portions of this post come from details in the SiteMinder Policy Server Configuration and User Context Gateway Guides Copyright © by CA Technologies.

Overview:
In a Windows network, a security context defines a user’s identity and authentication information. Web applications such as Microsoft Exchange Server or SQL Server need a user’s security context to provide native security in the form of Microsoft’s access control lists (ACLs) or other access control tools. The SiteMinder Web Agent can provide a Windows user security context for accessing Web resources on IIS Web servers. By establishing a user’s security context, the server can use this identity to enforce access control mechanisms. This approach can be used to supply the security context to applications that call native .NET (or other) methods to get the user and associate security information.

There are several requirements to use SiteMinder’s native mechanism to establish the security context in IIS:

  • Active Directory must be used as the user store with the “Use authenticated user’s security context” option checked.
  • The SiteMinder Session Server must be configured and enabled on all the Policy Servers. The Session Server requires a relational database (e.g. MS SQL) in which to store session information.
  • The realm protecting the applications requiring the user’s security context must have Persistent Session enabled.

The session server stores a user’s encrypted credentials and associates the user with a session ID. When a SiteMinder session is established between a client and a Web Agent, the Windows user account is established and linked to the session.

Considerations:
There are several considerations to keep in mind when using SiteMinder to establish the Windows Security Context. These items may impact the ability to leverage SiteMinder functionality for this purpose.

The following items should be considered:

  • The user must initially authenticate to a realm with Persistent Session enabled. This is required to establish the initial session for the user in the session server and to capture the user’s credentials. In an environment where a user can authenticate to multiple realms, each of those realms must have Persistent Session enabled. A user may be re-challenged when entering a realm with Persistent Session enabled if the initial authentication was to a non-persistent realm. However, it looks like SiteMinder is instead throwing an error in that scenario.
  • The user must authenticate to Active Directory for the necessary information to be captured in the session store. When domains have a combination of multiple user directories of different types listed, the Active Directory user directory may need to be listed first to ensure that a user’s credentials do not match another directory prior to being authenticated to Active Directory. If that occurs SiteMinder will not be able to establish the user’s security context.
  • Persistent Sessions introduce performance implications since the session must be validated against the session server. This can be minimized by setting the validation period on the session to a high value to reduce the number of times the session is checked. The validation period should be set less than the idle timeout value. Once a persistent session is established for a user, the users session is always validated against the session server regardless of if the realm being accessed has persistent session enabled. Using security zones for the Web Agents protecting applications requiring persistent sessions constrains the session validation to that zone only. This eliminates the need for other agents to validate the session with the session server.
  • Environments with global implementations require either the session database to be replicated in real-time to each data center or for the Policy Servers to point back to a common session store across the network. If the Policy Server does not have the session server enabled or is pointed to a database that does not contain the user’s session, the user will be re-prompted for authentication. Pointing at a database across the network to a common session store eliminates that issue, but due to the latency and frequency of the calls to the session server this is not recommended.
  • Only authentication schemes that leverage an ID and password can be used with SiteMinder’s capability to establish the Windows Security Context. The following authentication schemes are supported:
    • Basic Authentication Schemes
    • Basic Over SSL Authentication Schemes
    • HTML Forms Authentication Schemes
    • X.509 Client Certificate and Basic Authentication Schemes
    • X.509 Client Certificate and HTML Forms Authentication Schemes

Other Options:
Since third-party Web Access Management (WAM) systems are fairly prevalent, modern applications should support the capability to integrate with this type of system. This is usually done by trusting a header or token created by WAM system that contains the user’s identity. For SiteMinder the application should read the SM_USER header or allow the option to specify a header that contains the user’s identity. SiteMinder can then set the appropriate header using a response that ties the header to the specific identity attribute in the underlying user store.

In cases where that is not possible and the SiteMinder native capabilities to establish the security context do not meet the specified requirements, CA has a solution module called the “User Context Gateway” that can establish the security context for the user. The User Context Gateway (UCG) is used for three purposes:

  • Establishing a Windows Security Context under IIS.
  • Capturing a user’s sign-on password for later use.
  • Maintaining and verifying a Windows password independent of the user’s sign-in (also known as “directory”) password.

UCG differs from SiteMinder native security in the following ways:

  • All user directories that are writable to SiteMinder can be used by UCG. SiteMinder natively requires Active Directory as the user store.
  • The session server is not required for UCG.
  • All authentication schemes are supported by UCG. SiteMinder natively requires authentication schemes that leverage an ID and password.
  • The user’s credentials are stored persistently in the user directory instead of being stored in the session store.
  • While not recommended a user’s credentials can be made available to third-party applications. SiteMinder natively can only supply the user’s password to the first resource requested after authentication.

Since the User Context Gateway is a solutions module, there may be additional costs for this solution. Compatibility with the deployed version of SiteMinder should also be validated.

Configuring SiteMinder to Establish the Windows Security Context:

The following steps outline what is required to configure SiteMinder to establish the Windows Security Context for the user:

  1. Create the session server database and run the relevant SQL scripts to create the tables, etc.
  2. Define the ODBC data source for the session database.
  3. Configure the session database on the Data tab of the Policy Server Management Console and enable the session server.
  4. Enable the user directory containing the Windows users to run the security context by checking the “Use Authenticated User’s Security Context” check box on the Directory Setup group box on the User Directory pane.
  5. Associate one of the authentication schemes defined in the Considerations section with each realm where a user can authentication in the resource group box of the Realm pane.
  6. Enable persistent sessions for each realm and set a high Validation Enabled period with each realm where a user authenticates or the Windows Security Context is required in the session group box of the Realm pane.

Refer to the relevant SiteMinder documentation for details on how to perform these steps.


Tags: , , , , ,
Posted in Identity and Access Management | 4 Comments »

Working Around SiteMinder 500 Errors for Unauthorized Federation Service Provider Access

Wednesday, September 7th, 2011

Overview:
SiteMinder provides federation capabilities for SAML (and other protocols). SiteMinder’s federation capabilities are accessed through a set of web services installed with the Web Agent Option Pack. The federation web service throws a 500 error instead of automatically redirecting the user for re-authentication like a standard SiteMinder Web Agent when the user has a valid SiteMinder session, but is not authorized to access the configured SAML Service Provider. This can be worked around in a couple of ways, but one way to handle this is to leverage the federation 500 error redirect to automatically redirect the user to a page which logs the user out and then redirects back to the federation URL.

The following is required for this configuration:

  1. Custom redirect page that takes the federation POST variables and redirects the user back to the sent SPID. This page should be placed on a web server with an installed SiteMinder Web Agent.
  2. Configure the redirect page as the logoff URI within the agent’s configuration object (ACO).
  3. Set the custom error page as the Server Error URL in the Additional URL Configuration section on the Advanced tab of the SAML service provider configuration dialog.

Custom Redirect Page:
The custom redirect page can be an ASP, ASP.NET, JSP or any other dynamic page that can take POST parameters, parse them and redirect the user back to a URL. The following ASP code is an example of a page that takes the information from SiteMinder and redirects the user back to the federation URL:

<%
Dim relaystate, spid, fedurl, redirecturl
relaystate=Request.Form("RelayState")
spid=Request.Form("SPID")
fedurl="https://saml.company.com/affwebservices/public/saml2sso"

if relaystate = "" Then
 redirecturl=fedurl+"?SPID="+spid
Else
 redirecturl=fedurl+"?SPID="+spid+"&RelayState="+Server.URLEncode(relaystate)
End If
%>

<html>
<head>
<title>Redirect Page</title>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
</head>
<body>
<% Response.Redirect(redirecturl) %>
</body>
</html>

To use this code, set the fedurl variable to the base federation URL for the environment. The page should then be dropped on a server with a SiteMinder Web Agent in an unprotected folder. For example in a folder like:

<WWW root>\redirect\logoffredirect.asp  (is the file was an ASP named logoffredirect.asp)

where <WWW root> is the base document folder for the web server site.

Configure the Page as the LogoffUri Agent Parameter:
Setting the custom redirect page as the logoffUri for SiteMinder ensures that the SiteMinder session is ended so that when the user is redirected page to the federation URL they will then be prompted to log in again. In the example above, the URI for the page is /redirect/logoffredirect.asp. To add this:

  1. Open the Agent Config Oject (ACO) for the Web Agent  installed on the server with the custom redirect page.
  2. Uncomment the LogoffUri parameter and add the URI (not URL) for the custom redirect page.
  3. Save the ACO.

The configuration change will be automatically picked up be the agent. In this example, the ACO looks like the following image:

Set the Server Error URL:
Once the custom error page is deployed and configured as the LogoffUri, the next steps is to tell SiteMinder to redirect to this page when the user would normally receive a 500 error from the federation web service. While we are using to redirect the 500 error thrown when a user is not authorized, this has the side effect of sending all 500 errors to the redirect page. This may or may not be an issue in your environment. To configure the Server Error URL:

  1. Open the SiteMinder FSS Administrative UI.
  2. Click on the Domains tab.
  3. Open the federation domain.
  4. Click on the SAML Service Providers left-nav item.
  5. Open the Service Provider configuration.
  6. Click on the Advanced tab.
  7. Click the [Custom Error URL Config] button.
  8. Check the Enable Server Error URL checkbox.
  9. Enter the URL for the custom redirect page (e.g. https://saml.com.com/redirect/logoffredirect.asp).
  10. Change the drop-down to Http Post.
  11. Save the configuration.

Setting the drop-down to Http Post is required so that the necessary information is sent to the redirect page. This allows the redirect page to redirect the user back to the correct Service Provider configuration. Making the redirect page dynamic ensures that a common redirect page can be used for multiple Service Provider configurations.

 

Tags: , , , ,
Posted in Identity and Access Management | 4 Comments »

Configuring SiteMinder SNMP on Red Hat 5

Tuesday, August 9th, 2011

Note: Portions of this post come from details in the SiteMinder Admin and Install Guides Copyright © by CA Technologies.

Overview
This post cover details on how to configure SiteMinder’s SNMP services on Red Hat 5.  The SiteMinder SNMP module enables many operational aspects of the SiteMinder environment to be monitored by SNMP-compliant network management applications. The SiteMinder SNMP module provides SNMP request handling and configurable event trapping for the SiteMinder environment. It does this by collecting operational data from the SiteMinder OneView Monitor and making it available in a MIB to third-party Network Management Systems applications (NMS) that support the SNMP protocol.

The SiteMinder SNMP module consists of:

  • SiteMinder SNMP MIB is the database of SiteMinder objects that can be monitored by an SNMP-compliant network management system.
  • A SiteMinder SNMP Subagent responds to SNMP requests (GET and GETNEXT only) passed to it from an SNMP master agent.
  • SiteMinder Event Manager captures Policy Server events and, if configured to do so, generates SNMP traps (unsolicited messages sent by an SNMP agent to a SNMP NMS indicating that some event has occurred).

The SNMP support is dependent on OneView monitor being installed and configured on the Policy Server and also requires a Master SNMP Agent at the Operating System level.

The following figure illustrates SNMP module dataflow:

SiteMinder SNMP Dataflow:

  1. The SNMP Master Agent receives SNMP requests from a management application.
  2. The SNMP Master Agent forwards the SNMP request to the SNMP Subagent.
  3. The SiteMinder SNMP Subagent retrieves the requested information from OneView Monitor.
  4. The SiteMinder SNMP Subagent passes the retrieved information back to the SNMP Master Agent.
  5. The SNMP Master Agent generates an SNMP response and sends it back to the requesting management application.

The SiteMinder MIB provides an SNMPv2-compliant data representation of all monitored components in the SiteMinder environment.  The SiteMinder MIB is supplied in an ASCII text file and should be sent to the monitoring team for interpreting the SNMP information from the Policy Server.  The MIB is located at:

<SiteMinder Home Directory>/mibs/NetegritySNMP.mib

Refer to the Policy Server Administration Guide for details on all the SNMP information provided by SiteMinder.

SNMP Base Configuration

While SNMP support can be configured manually, the Policy Server Configuration Wizard will be used to enable SNMP support.  By default port 161 and 8001 must be open on the box for the SNMP Master and Sub-agent.  This post assumes that you can the ability to become root on the server.

To configure SNMP:

  1. Log in to the Policy Server using ssh
  2. Become root: >sudo su – root
  3. Source the ca_ps_env: >source <SiteMinder Home Directory>/ca_ps_env.ksh
  4. Run the Policy Server Configuration Wizard: ><SiteMinder Home Directory>/ca-ps-config.sh -i console
  5. When the wizard loads select 3 to configure SNMP support
  6. Review the Pre-Configuration Summary and Press <Enter> to continue (I have installed to /opt/SiteMinder)
  7. The wizard configures SNMP support for the Policy Server
  8. At the SNMP Configured message press <Enter> to accept the message
  9. At the Installation Complete message press <Enter> to exit the installers

The base components for SNMP support have now been configured.  The SNMP Master Agent, SNMP Sub-Agent and Policy Server must be restarted after the configuration is completed.  See below for details on stopping and starting the SNMP Master and Sub-Agent.  The Master SNMP Agent must be restarted as root.  The Sub-Agent can also be started as root.  The Policy Server should be stopped/started as the SiteMinder user.

SNMP Agent Configuration

Once the Policy Server Configuration Wizard completes the SNMP configuration, the server should be set up with the values specific to your implementation.  The wizard configured the SiteMinder SNMP files at <SiteMinder Home Directory>/etc/snmp/conf and modified the snmpd.conf system file at /etc/snmp to include the line:

proxy -c public -v 1 localhost:8001 .1.3.6.1.4.1.2552

To change the SNMP community string to something besides public:

  1. Log into the Policy Server through ssh
  2. Become root: sudo su – root
  3. Edit the snmpd.conf file: vi /etc/snmp/snmpd.conf
  4. Go to the end of the file
  5. Edit the “-c” parameter to change the value from “public” to the desired community string
  6. Save the file

The SNMP sub-agent uses port 8001 to listen for SNMP requests.  To change the local port that the SiteMinder SNMP sub-agent is using:

  1. Log into the Policy Server through ssh
  2. Become root: sudo su – root
  3. Edit the SiteMinder RunSubagent.sh file at: >vi <SiteMinder Home Directory>/etc/snmp/conf/RunSubagent.sh
  4. Change the following line to the desired port: AGENTPORT=8001
  5. Save the file
  6. Edit the snmpd.conf file: >vi /etc/snmp/snmpd.conf
  7. Go to the end of the file
  8. Edit the “localhost:8001” parameter to the port specified in step 4 above
  9. Save the file

The SNMP Master and Sub-Agent must be restarted for these changes to take effect.

SNMP Trap Configuration
SiteMinder can send SNMP Traps (alerts) when certain events happen on the Policy Server. These traps are received by the configured NMS and processed according to the rules configured within that system. The following traps can be generated:

Event Name

  • serverInit
  • serverUp
  • serverDown
  • serverInitFail
  • dbConnectionFailed
  • ldapConnection-Failed
  • logFileOpenFail
  • agentConnection-Failed
  • authReject
  • validateReject
  • azReject
  • adminReject
  • objectLoginReject
  • objectFailedLogin AttemptsCount
  • emsLoginFailed
  • emsAuthFailed

Enabling SNMP Traps is broken down into three steps:

  1. Enable SNMP event trapping
  2. Configure the SNMP Trap Config file
  3. Restart the Policy Server

Enable SNMP Event Trapping
The XPSConfig utility is used to enable the SNMP trap event handler.  The library, libeventsnmp.so, is used to generate SNMP traps.  The library is located at:

<SiteMinder Home Directory>/lib

The library needs to be added to the XPSAudit list. Use the following steps to add the event handler:

  1. Log into the Policy Server through ssh
  2. Become the SiteMinder user
  3. Enter the following command: >XPSConfig
  4. The XPS Configuration utility starts
  5. At the Products menu enter: XPS
  6. Press <Enter>
  7. Enter 5 for the AuditSMHandlers option and press <Enter>
  8. The Audit Handler option menu appears
  9. Enter the following option to add the SNMP Trap library: C
  10. Press <Enter>
  11. Enter the following path to the SNMP Trap library (if there is an existing value keep, enter the existing value again and enter a comma before adding the SNMP Trap library): <SiteMinder Home Directory>/lib/libeventsnmp.so
  12. Press <Enter>
  13. The settings for the event handler libraries appear. The value you added is shown at the bottom of the settings as a “pending value.”
  14. Enter the Option: Q
  15. Enter the Option: Q
  16. Quit XPSConfig by entering: Q

Your changes are saved and the command prompt appears.

Configure the SNMP Trap Config File
You configure the SiteMinder SNMP Trap Event Manager by defining the event in the Event Configuration File, <SiteMinder Home Directory>/config/snmptrap.conf, which defines what events are to be processed and the addresses of the Network Management System to which the traps should be sent.

The snmptrap.conf is an editable ASCII file, with a simple one line per event syntax:

Event Name               Destination Address             Community String

Event_Name: The name of a MIB event object (or a comma-separated group of names of event objects).

Destination_Address: The address of the Network Management System (or a comma-separated group of the addresses) to which generated traps should be sent. Each address should be of the form:

HostID:port

HostID (mandatory): Either a hostname or IP address

Port (optional): IP port number (default is 162)

Community String (optional): An SNMP community. Note that if community is specified, Port must also be specified.  The default value is public.

To configure the snmptrap.conf file:

  1. Log in to the Policy Server using ssh
  2. Switch to the SiteMinder user
  3. Edit the SNMP Trap Config file: >vi <SiteMinder Home Directory>/config/snmptrap.conf
  4. Uncomment the lines for any desired traps
  5. Specify the IP Address, port number, and community for where you want the trap to be sent
  6. Save the snmptrap.conf file
  7. Restart the Policy Server

Stopping and Starting the SNMP Master and Sub-Agent
In order for the SNMP configurations changes to take effect, you need to stop and restart the Policy Server using the Status tab of the Policy Server Management Console.  Additionally, the SNMP Master and Sub-Agents should be restarted when there are changes to the SNMP configuration.  The server start-up scripts should be modified to automatically start the Master and Sub-Agent.

Stopping and Starting the SNMP Master Agent
To stop the SNMP Master Agent:

  1. Log in to the Policy Server using ssh
  2. Switch to root:  sudo su – root
  3. Go to the /etc/init.d directory: >cd /etc/init.d
  4. Type the command: >./snmpd stop
  5. The following message is resturn: Stopping snmpd:                                            [  OK  ]

The Master Agent stops.

To start the SNMP Master Agent:

  1. Log in to the Policy Server using ssh
  2. Switch to root:  sudo su – root
  3. Go to the /etc/init.d directory: >cd /etc/init.d
  4. Type the command: >./snmpd start
  5. The following message is resturn: Starting snmpd:                                            [  OK  ]

The Master Agent starts.

Stopping and Starting the SiteMinder SNMP Sub-Agent
To stop the SiteMinder SNMP Sub-Agent:

  1. Log in to the Policy Server using ssh
  2. Become root: >sudo su – root
  3. Source the ca_ps_env: >source <SiteMinder Home Directory>/ca_ps_env.ksh
  4. Change to the SiteMinder snmp directory: >cd <SiteMinder Home Directory>/etc/snmp/conf
  5. Type the following command: >./StopSubagent.sh

The SiteMinder SNMP Sub-Agent stops.

To start the SiteMinder SNMP Sub-Agent:

  1. Log in to the Policy Server using ssh
  2. Become root: >sudo su – root
  3. Source the ca_ps_env: >source <SiteMinder Home Directory>/ca_ps_env.ksh
  4. Change to the SiteMinder snmp directory: >cd <SiteMinder Home Directory>/etc/snmp/conf
  5. Type the following command: >./RunSubagent.sh &

The SiteMinder SNMP Sub-Agent starts

 

Tags: , , , , , ,
Posted in Identity and Access Management | No Comments »

Collection of Useful SiteMinder Videos

Friday, June 3rd, 2011

CA SiteMinder is a sophisticated product with a considerable number of options and deployment scenarios.  The product also is constantly evolving to meet new requirements and challenges.  This post contains links to some of the recent videos that we have found which provide some good insights into product basics, new functionality and ways to get the most out of your deployment:

Have you come across any other useful videos?  If so, post the links in the comments below.

Tags: , , , , , ,
Posted in General, Identity and Access Management | No Comments »

Putting the Practical Back in IAM

Wednesday, June 16th, 2010

2353470227_cf37943a16-1Let’s face it: explaining Identity & Access Management to a layperson isn’t easy. How often do those of us who work in the space respond to the simple question “so what do you do?” at a cocktail party or a family event, only to see that familiar glazed-over expression less than 30 seconds into our reply? IAM is a space that’s prone to acronyms and cryptic concepts: SSO, virtual directory, WAM, federation, SAML, LDAP, etc. Of course, the issue here is not so much that these concepts are over your grandmother’s head. The problem comes when your grandmother is a high-level executive trying to figure out how IAM is going to provide significant ROI for her company. As product and service providers in this space, we’re the ones responsible for making the practical case for Identity & Access Management. My belief is we could all be doing a better job of this.

The inspiration for this post was a recent interview conducted with Dieter Schuller, VP of Business Development for our partner Radiant Logic. The interview covers its own fair share of acronyms and concepts, most of which are at the core of what this blog’s readership does for a living. But eventually it shifts into a practical (and very powerful) example of what identity correlation can do for a business, courtesy of Dieter:

For example, we just worked with a major electronics company, where they started with access management, single sign-on, delegated administration, but they wanted to make their portal a much better experience so when the user logged in, rather than just serving up products, the idea is you know enough about me because you have an order entry system that tracks what I bought online, you have a product registration system that tracks what I bought offline, you have a product database so you know that I bought a camera and now you should try to sell me a camera case.

They actually took it a step further and actually integrated it to their partner systems as well. They have a relationship with Facebook, for example, and, for that particular identity, started to look at what their movie and music preferences are and serving up content based on that.

Take a step back and think of what this interview would have meant to a non-IAM professional had it not included this real-life scenario. I think it would have led to multiple Google searches to define MDM, CDI, virtual directory, etc, if the reader had the time. Instead the reader comes away thinking about what this technology meant to an electronics company and how this might help his/her own business. In the real world this can mean the difference between a company becoming a prospect, and a prospect becoming a client or a customer.

“For example” can be powerful words in the context of security technology. We need more for examples in this space, not less. Have you seen examples of IAM companies providing practical real-world descriptions of how their products and services are being leveraged? If so, please share in the comments!

Tags: , , , , , , , , , , , , , , ,
Posted in Identity and Access Management, Virtual Directory | No Comments »

SiteMinder Experts List

Wednesday, February 10th, 2010

2310866391_eef389df61_mOver the past year we’ve seen a definite rise in the number of SiteMinder conversations on social networks. Whether it’s job opportunities, technical issues, or SiteMinder tips, the social universe is talking about the enterprise security application we’ve all come to know and love (always love, right? ;-) ).

One thing we’ve noticed that the SiteMinder community can do a better job of is helping people to understand where to look for help with their SiteMinder needs. On the Twitter side, we’ve created a list of SiteMinder professionals who frequent that network. These are folks we’ve interacted with or accounts that tend to generate interesting links related to SSO and enterprise security.

Of course, you can also sign up and participate in our SSOhelp community.

By the way, good news for those of you who are interested in Radiant Logic VDS: there’s a list for you too! Follow our list of Radiant Logic professionals.

We’ll continue to grow both lists over time, and if you feel you should be added then feel free to drop us a line @coreblox.

http://www.flickr.com/photos/fboyd/ / CC BY-SA 2.0

Tags: , , , , , , , , , , ,
Posted in Identity and Access Management, Social Networking, SSOhelp.com, Virtual Directory | 1 Comment »

CA SiteMinder Expands Open Source Support

Monday, February 8th, 2010

opensource_logoThis morning I noticed an interesting item in my news feed that CA SiteMinder has been expanded to support web applications and services running on JBoss Enterprise Middleware. This means that popular platforms such as JBoss Enterprise Application Platform, JBoss Enterprise Portal Platform, and JBoss Enterprise SOA Platform are now fully in play for CA SiteMinder customers.

Anyone who is familiar with enterprise software can tell horror stories about its acquisition & maintenance costs, not to mention the frustration that comes when an internal team identifies a bug that must await a formal fix from the vendor because its root cause lies in the source code. Only those who have experienced this pain can fully appreciate the value of the open source model. The CoreBlox team leveraged an open source platform during the early stages of the company and we were continually impressed by the passionate community that backed it up and was always willing to help. It’s encouraging to see a large corporation like CA recognize the importance of extending SiteMinder support to those who choose to build their infrastructures (either solely or partly) on open source technologies. Well done, CA!

Tags: , , , , , , , , , , ,
Posted in Identity and Access Management, Interesting Info | No Comments »

CoreBlox.com Changes

Tuesday, January 19th, 2010

If you’re paying close attention to the CoreBlox web site (and I know you are!), you might have noticed some recent changes we’ve made to better answer that age-old question: what the heck do you guys do?? The truth is that most of our consulting work centers on some specialized enterprise security concepts and technologies that our visitors have never heard of. So to offer a little more guidance, we’ve added a new CoreBlox Technologies section. The sub-pages in this section include:

Keep watching for more changes we’ll be deploying in the coming weeks. In the meantime, we’re here to help. Please don’t hesitate to contact us if you’re in the midst of planning new initiatives, or even if you just want to bounce some ideas around. Also check out our SSOhelp community where some of the brightest minds in the security space are exchanging ideas and helping each other through tough challenges.

Tags: , , , , , , , , , , , , , , ,
Posted in CoreBlox News, Identity and Access Management, SSOhelp.com, Virtual Directory | No Comments »

Why RockYou Should Have Federated Identities

Friday, December 18th, 2009

In case you haven’t seen the news, RockYou‘s users have become casualties in the latest web privacy breach. TechCrunch detailed RockYou’s numerous transgressions here:

Earlier today news spread that social application site RockYouhad suffered a data breached that resulted in the exposure of over 32 Million user accounts. To compound the severity of the security breach, it was found that RockYou are storing all user account data in plain text in their database, exposing all that information to attackers. RockYou have yet to inform users of the breach, and their blog is eerily silent – but the details of the security breach are going from bad to worse.

32 million users. If you thought you were having a bad day, imagine what RockYou’s leadership team is dealing with. Winning back the trust of a single user can be challenging, let alone the other 31,999,999.

RockYou has some 'splaining to do

RockYou has some 'splaining to do

Of course it’s easy to pile on RockYou for the many boneheaded decisions that led to this breach. Users can’t protect themselves if they don’t have the proper tools, and the act of promoting the use of simple passwords by practicing non-existent password policies is a virtual invitation to hackers. Sadly enough, even stricter policies could not have saved RockYou since they elected to store passwords in the clear. In the applications world this is the ultimate rookie mistake, and it’s difficult to imagine a company like RockYou making it.

Unfortunately the impact of RockYou’s mistakes has ripple effects for other social network partners. As TechCrunch revealed, RockYou collected user credentials for integrated sites such as Facebook and MySpace and stored them (in clear text) in their database. So if you’re one of the unfortunate RockYou users who submitted login credentials for both those networks, you have more than just your RockYou data to worry about.

So besides following through on their promise and not storing the data to begin with, what could RockYou have done to work around the issue of exposing login credentials from their partner networks to hackers? That’s easy: FEDERATE! Federated authentication is a protocol that allows companies to trust incoming login requests from known sources, thereby eliminating the need for storing a separate login and password. Simply stated, federation is single sign-on deployed across the internet. This means user identities are more portable, the user experience is more seamless, and the login data is more secure since it does not need to be stored in multiple locations.

Facebook Connect login option

Facebook Connect login option

Sounds complicated, right? But the reality is you’re probably already using forms of federation in your every day web experience. Authentication services like Facebook Connect and Twitter’s oAuth are examples of federation in action. Why expose yourself to more risk by storing credentials when you can simply piggyback on what your partner is already doing?

Of course, the value of federation isn’t limited to social networks. Large enterprises like CA are using federated security models to drive partnerships and other business relationships. Our own Todd Clayton has described a vision for a Federation Oriented Architecture where the principles of identity federation are applied other data. There is no doubt the need for identity federation is on the rise, and we expect to see plenty of work in this area in 2010.

Unfortunately hindsight cannot save RockYou from the embarrassment over this mess. The users who choose to stay with them can only hope they’ll learn from their mistakes.

Tags: , , , , , , , , ,
Posted in Federation, Identity and Access Management, Social Networking | No Comments »

Video: Extending SiteMinder with RadiantOne

Tuesday, August 25th, 2009

Last month, our very own Todd Clayton presented a webinar for Radiant Logic called “Evolve Your SiteMinder Portal Through Virtualization—Without Breaking the Bank”.  He discussed the benefits of using a RadiantOne virtual directory with CA SiteMinder, some of which include:

  • Identify, correlate, and integrate identities from multiple user populations across security domains.
  • Publish different profile views for SSO, authorization, and profile management.
  • Create unified profiles of all users for different application contexts.
  • Build an abstraction layer so SiteMinder can access attributes without any changes to your existing infrastructure.
  • Develop an environment that easily accommodates future expansion and new business requirements.

Please feel free to contact us for more info on how these two products can work together.

-Dave

Tags: , , , , , , , ,
Posted in Identity and Access Management | No Comments »

« Older Entries