SSO and the Organization
Quinton Wall's Blog |
October 7, 2005 10:44 AM
|
Comments (0)
I have been heads down for the past few days assisting a client on
their SSO strategy. It is amazing how much disinformation is out there
on the subject of single sign-on and the components involved. In my
opinion many vendors spend so much time focusing on technical details
and make things just too complex.
vendors etc
Sure there are many technical issues that must be addressed in regards
to an SSO solution such as SNPEGO, Kerberos, Web Services, LDAP stores etc but I
find that these issues can usually be solved quickly and easier; often
in a generic manner. The references
below may assist people in getting a heads up to BEA's pluggable
Security Architecture provider model.
With such information easily
available I am not going to spend my time rehashing all of this but
suggest that the more complex aspects of SSO relate to changing business
processes and organizational change. This is not dissimilar to
many of the issues faced with a SOA implementation without some of the
governance impedance that often occurs.
Very often SSO solutions
include some form of Directory User Store such as Active Directory,
OpenLDAP, OiD etc. Weblogic Server provides a number of
Authenticators
which make interacting stores with these straightforward and very
configurable. The problem usually arises when, through investigation
of the deployment topography, it becomes apparent that subsystems almost
always contain user credentials of their own with unique names etc.
Somehow, these credentials need to be synchronized with a central user
store that your Weblogic Authenticator refers to. Centralizing what I
like to call 'first-touch' security is very important to long term
maintenance and scalability. Organizations must define a process for
retrieving details from these subsystems and populating a central store.
Of course, having a single store is not always required. For example
if the solution utilizes client certificates such as Kerberos token etc
the organization needs to implement some process of allowing users
to obtain a valid certificate and then provide some form of
Identity Asserter to confirm that the person presenting the
system is really who they say they are. This approach to SSO infers that
subsystems shall be configured for client certificate authentication.
Any failed authentications shall be handled individually by the subsystems.
In addition, organizations often want to produce some form of umbrella
system that provides a integrated perspective to end users. This is often
where a portal solution begins to make sense.
One of the nice things about using the Active Directory or LDAP
Authenticators is the ability to configure them to dynamically populate
group membership based on distinguishing features of their AD/LDAP
profile such as organization unit, group base name etc. With the Weblogic
Platform groups defined at the server level can very easily be mapped
to Portal roles and groups. In most instances this happens
automagically for you. The benefit of such an integrated platform for
SSO initiatives is the ability to minimize future synchronization
and management issues that occur from multiple 'touch points'.
I have barely touched the surface of some of the Organizational complexities that may arise from single sign-on initiatives. The great news is
that with careful planning of current requirements, future needs and,
best of breed software, technical considerations may not take up all
your IT budget and leave you more flexibility to begin to expose a
service infrastructure the will grow with your business.
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
|
