Some Challenges in IDM project implementation

After working/talking about multiple IDM implementation I feel that there are different kinds of challenges in implementing the solution.




1) Getting the approvals/access from the end application : For example integrating with Oracle financial system one needs to have super user kind of permissions on the system for provisioning/deprovisioning. End application teams have there valid concerns for not giving that kind of access to IDM system.




2) Password policy : One of the very good feature of IDM system is to provide password synch across organization wide applications. In real world it becomes very challenging because of all systems does not have same password policy for one reason or the other.




3) Unique ID for life : If not all but most of the organizations work in the employee/consultant mode. People change there profile from employee to consultant and vice versa. It is a real challenge to find the same person in the system if S/he is returning to the organization. Organizations spreaded across globe are having this as a bigger challenge because they are working to consolidate there HR system under one umbrella to have better control over the system.




4) Missing unique ID in the applications : In the ideal world we expect end application which is getting integrated with IDM will have one or the other co-relation key to allow IDM to reconcile the accounts but it is not always true. Some times IDM teams have to request changing the end applications to have an extra field storing the co-relation key.

Adaptive Access Control

Few weeks back I went to attend Oracle Openworld in San Francisco and while I was on the demo grounds to see what oracle has to offer in the Identity and Access Control I met one product group which is building a "Adaptive Access Control" product.

This product builds the intelligence based on your previous access controls and compare them on next logon. This can be configured to make the metrics over a predefined period of time and freeze the statistics for next access requests.

For example if you are accessing the system between 8AM and 5PM on a daily basis and one day it gets the request at 10PM then it will deny the access.

This seems a good idea to me except for the reason that how long it takes to capture the metrics and how it handles the exceptions.

Another scenario could be that you access the system from North America reason and one day it sees the request from India then it has a valid reason to suspect the request.

Open Source identity and Access management : VELO

Fortunately I got a chance to directly talk to Asaf Shakarchi (father of VELO) and I asked him why you named it VELO.

Asaf: It was taken by "velo binding". You can read about it in wiki.

My understanding: I then read about it in the Wiki and tried to link it with the identity and access control and realized the name is so true as the product is also trying to link and bind and control the identities.

I also asked him what is the function of remote performer and below is what I understood from his explanation

Remote performer is a kind of load balancer which can be used to delicate the responsibility of the VELO server. For example if the environment has many resources and you don't want to wait for the responses from the resource once you provision, you can use VELO remote performer. All the requests will be delegated to the remote performer and VELO server can perform other important tasks.



Remote performer is not a must for deploying VELO but it can give additional flexibility to distribute the load.

Oracle database security and PCI DSS

Today I was browsing for data masking technology and products available in this space and found one good link on the oracle site.

This link explains each PCI DSS requirements in detail.

Strong Authentication by biopassword

I watched many sci-fi movies where guys were playing around on the keyboard and trying to hack someones system by figuring out password etc. You already know that every individual has his/her own way/speed of typing on the keyboard. Biopassword has made a product on such grounds. There product captures the keystrokes and builds a pattern in which user key in the password etc. During authentication there software checks for that pattern and denies the access if the pattern does not match. I have tested the demo on there site.

You check it out by yourself and have fun.

SAML and desktop SSO

Today I was reading a post and found one good blog which i would like to share with you. PingIdentity has developed Integrated Windows Authentication toolkit to provide SSO to Google application.

If you have read my post onSAML where I discussed how Google apps are using SAML for federated authentication to there applications like gmail/gtalk used by corporates with there domain like abc@company.com hosted using gmail interface. In that post I have mentioned under section 1-a that if user is already authenticated then identity provider will not ask for the credentials again to the user but directly give access to the Google application like gtalk/gmail etc.

Below diagram shows my understanding of how it might be working. I am not showing anything related to pingidentity implementation for this approach but it is completely my understanding for the solution.

Microsoft GINA component can be customized to get the user credential and Microsoft has also exposed API to set the cookie for Internet explorer. Keep in mind that all things are going through the user browser so if user has a cookie to some domain (identity provider) it will be sent to the server by the browser.

Similarly Cookie can be deleted on the event of user logout. If the solution needs persistent cookie can also be set which will expire after the persistence time.

ProQuo Implementation of centralized identity

Many people staying in USA (Sorry for being location specific as this implementation is done for USA) are suffering with tons of junk mails coming to there mailbox (Physical mailbox). Here publisher/marketing organizations send lots of advertising material to the mailbox which (80-90%) directly been dumped into the trash box next to the mailbox. It consumes billions of dollars cost of paper and postage.

This new site is a good effort to stop this unnecessary mails coming to your mailbox. Once you login/register at this siteProQuo it will display all the publications which you are getting. After registration you can view your current publications by clicking on the dashboard link.

Below image shows how ProQuo might be getting the publication information's from different marketing organizations.



Once a person registers with his [name/email and address] this site can show how many publications you have. They might able to collect this information based on your identity (Name + Address).

When I registered on this site and tried to stop some of the publications I got stuck with some paper work (You have to take the printout of the PDF file which has the letter to stop the publication and post it to the publisher). Problem with this is that most of the people have at least 10-15 publications. Every publication post is going to cost 50 Cents so roughly 5$ per household to stop all the junk publications.

Identity Solutions:

I feel that the wired solutions can be built to stop the physical communication between the user and the publisher. Following could be some of the ways to implement this

1) Using SAML: user assertion can be sent to the publisher over the wire. This SAML assertions can also contain the encoded PDF letter which can be used as a proof at the publisher.

2) Using custom Cryptography: User's signed PDF can be sent to the web service running at the publisher when user want to stop the publication.

Share your comments about how it can be implemented.

Technorati : federated identity management, identity control, identitycontrol

How Kerberos was evolved - Inside Story Part 2

In my last post I discussed few steps for the evolution of kerberos protocol implementation. In this post I am going to conclude it so read on...

Just want to recolect the problem statements where I left in last post so you get some continuity

Problems

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

For solving first problem Authentication Server (Ticket Granting Server [TGS]) will generate a sessionkey which will be sent to the user. TGS will also send a ticket encrypted with service password to the user. Below is the detailed structure

[SesssionKey:[*Service Ticket encrypted with service Key]]

* Structure of service ticket is [SessionKey:lifespan:issuing time:service name]

issuing time and lifespan are introduced so tickets can be valid for specific amount of time and not good for ever.

TGS will encrypt session key and ticket with user's password to solve the replay attack because password is only shared between user and Authentication Server.

Step by Step process for user authentication and service access

1) User enters the userid and KINIT program on the user machine sends that to TGS for authentication.

2) TGS server creates Ticket Granting Ticket [TGT] (this will be used to get service tickets)and send to the user by encrypting the whole content by users passwod.

3) User decrypts the TGT using the password to get the ticket. If someone spoof the packet then he will not be able to decrypt it as the password is shared between user and TGS only.

4) User wants to access his mail but user does not have mail service ticket so user contacts TGT for mail service ticket by submitting Authenticator,TGT, Name of the user and workstation address. This Authenticator with the session key sent by the TGS in the initial handshaking.

* Authenticator = {username:servie name: time stamp : lifespan}

5) TGS will get the session key of the user and decrypts the authenticator. After validating the identity it generates following and send by encrypting the whole content using the SESSION Key.

i) Ticket for the mail service. This ticket has the session key, service name, lifespan, timestamp and client address. This ticket is encrypted with the service password. (Even User can not decrypt it)
ii) Session key to be used to encrypt the conversation with mail service

6) User recieves the packet and decrypts the content using the session key (Given during first handshake with the TGS).

7) User prepares the Authenticator and encrypts it with the SESSION key (generated for the mail service communication in step 5).

8) Mail Service recieves the Authenticator and Ticket. Decryptst the ticket using it's password to get the session key. Using the session key decrypts the Authenticator. Validate the Authenticator and sends the acknowledgement to the user by encrypting the session key.

9) User receives the acknowledgement and start using the service.

How Kerberos was evolved - Inside Story Part 1

I always wanted to get something on kerberos (earlier name Charon) which can give me inside of the protocol like why,how, what etc...

In this post I am trying to explain this in some easy steps with problem and solution approach for the evolution of this protocol.

Below Image displays the first version of there discussion



Problem with the first version is that anybody can impersonate anybody easily so no security and accountability. There is no Authentication (NO PASSWORD) piece involved it is just the userid which you pass to get the service.

Below Image solves first problem by having a centralized authentication server. Every user and every service has a password which is stored in the authentication server named CHAROS.

Here is how it work

1) User Authenticates with the centralized server
2) Server authenticates the user and give him a TICKET (encrypted text which is encrypted with service password)

*encrypted text contains (Username and servicename and IP address of the user)
3) User passes this ticket to the service and service will verify user's identity to give access




Problems with this:

1) User has to authenticate every time user wants to use any service. For example user has got the TICKET for mail service but wants to print some mail then he has to again enter the password
2) Password is flowing on the network in clear text (people can capture the password on the network)


Above problem is solve by introducing another component called ticket granting service in the authentication service. It will grant the ticket which can be reused.

Another componet which is added at the system level is KINIT service which is responsible for handshaking with the authentication service. Here is how it works

1) KINIT service will take userid and password from the user and will pass the userid to the authentication service (it will NOT pass the password at all)
2) Authentication service will build the TICKET GRANTING TICKET and encrypt it with the user's password because it knows what the user password is.
3) KINIT will decrypt the token using user's password. If it is able to decrypt it successfully then user is authenticated.





Problems:

1) Once tickets are generated at the user system and passed over the wire for service access they can be tapped over the wire. For example user got the encrypted ticket during authentication process and it was successfully decrypted, Now user will pass this ticket to mail server for mail access. At this time someone can tap the ticket and replay it later.

2) Tickets are good for ever. Once assigned no ticket session expiry.

Keep reading this because I will post rest of the story in next post...

Free Sun Identity Management training

Today while browsing blogs for identity management I end up Marina Sum's Blog. She has posted the free 2 hour course from Sun to introduce about identity management suite and it's offering.

I mentioned last time that it is available only in USA but I asked my friend in Australia and he confirmed that it works there too.

Check it out.

Cross IDM product integration

In my coffee time I use to discuss with my friends about the projects on which they are working and how they are solving the problems. It could be related to IDM/IAM or it could be any other technology. Few days back I met with my friend who is working with web methods to integrate different applications. While discussing about it back of my mind was thinking can we have something which can help us integrating multiple vendor products related to IDM / IAM space?

I think yes, that kind of framework can be built using the SAML and SPML specification integration framework. At the root level these specifications talks XML language over HTTP/S channel. If we can build a IDM middleware component which can understand one product language (XML Schema) and convert that to another product language then our purpose is solved.

It looks like OpenPTK is one such open source project on which Sun is working on. They recently released latest version of it. It is providing multiple interfaces to connect to Sun IAM suite (Identity and Access Control suite). But I think this is the starting as this version of OpenPTK does not support cross product integration.

OpenDS (open source directory server)

I am always deep lover of Directory Server and technology behind it. I was very happy when I saw that Sun (I have worked mostly with Sun LDAP and I love it) is aggressively working on a open source directory server project OpenDS which will take the directory server to new levels. I was reading about the intension of this project and why they have not supported the current open source projects like openLDAP,Apache directory etc and the reason they feel is because they want to redesign it based on current client's requirements.

Below are the features in the openDS:

Performance Lots of features are important, but performance is almost always near the top of the list. It needs to be extremely fast, outperforming all other servers wherever possible.

Upward Vertical Scalability. It needs to be capable of handling billions of entries in a single instance on appropriately-sized hardware. It should be able to make effective use of multi-CPU, multi-core machines with hundreds of gigabytes of memory.

Downward Vertical Scalability. It needs to be capable of running adequately in low-memory environments so that all essential components can be functional on edge devices like cell phones and PDAs.

Horizontal Scalability. It needs be possible to use synchronization to achieve higher levels of read scalability by adding servers to the directory service. In addition, it needs to be possible to use data distribution in conjunction with synchronization to achieve horizontal read and write scalability to achieve deployments into the billions.

Supportability. The server should be easy to support and maintain. Administration should be intuitive, and wherever possible the server should provide sufficient information and notifications to enable corrective actions, even predictively.

Security. The server must provide extensive security in areas like access control, encryption, authentication, auditing, and password and account management.

Extensibility. Virtually every aspect of the server should be customizable. It needs a safe and simple plugin API that delivers additional points of extensibility, including, but not limited to, password validation algorithms, password generators, monitor information providers, logging subsystems, backend repositories, protocol handlers, administrative tasks, SASL mechanisms, extended operations, attribute syntaxes, and matching rules.

Synchronization. The server must support data synchronization between instances, including not only total data synchronization but also partial synchronization (with fractional, filtered, and subtree capabilities), and must also provide a means of synchronizing with other applications and data repositories.
Availability. The server must be robust enough to continue running properly even if serious errors are encountered.

Portability. The server needs to be written entirely in Java so that it can run on any platform.

Reliability. A directory service is one of the most critical components of a business infrastructure. It is absolutely essential that the service function despite hostile or unexpected events and that the data it delivers be trusted.

Compatibility. The Sun Java System Directory Server will continue to be maintained over time and will not be immediately replaced by Sun products based on OpenDS. However, OpenDS must provide support for virtually all existing features of the Sun Java System Directory Server. Migration from other directory server implementations should also be taken into consideration when applicable.

PCI Compliance

Next buzzword of the coming year going to be PCI DSS (Payment Card Industry Data Security Standard). Since lots of identity theft and sensitive information is being attacked now a days it is very important to secure the MONEY and where ever in any form MONEY is :-)

Main goal of this compliance is to protect credit/debit card information where ever it is:
1) Issuing Banks
2) Online merchants like Amazon (They also store the credit card information)
3) Utility companies like your electricity provider. Now a days every one and mostly everyone accepts the online payment.
4) Even the merchants in the local store should comply to this standard because they are also playing with the card information's. If the merchant is dealing with debit card and PIN combination then they are exempted for PCI compliance.

Companies needs to get the confidence of the customers to provide the sensitive information (credit card information) for any kind of payments.This compliance standard is going to help the industry achieving the same.

Below are the PCI Data Security Standard Control Objectives & Requirements

I. Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters

II. Protect Cardholder Data
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks

III. Maintain a Vulnerability Management Program
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications

IV. Implement Strong Access Control Measures
7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data

V. Regularly Monitor and Test Networks
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes

VI. Maintain an Information Security Policy
12. Maintain a policy that addresses information security

Cross Site Scriptting

Cross Site Scripting is a web application attack which is also known as code insertion attack. It is basically of two types

1) Insertion of script in the server side, for example in the database content. Hacker may insert the script in the database by using forum postings etc. These scripts gets executed when user browses that page which uses the content having the hidden scripts.

2) Insertion of script content in the URL. Hacker may send these URLs by the channel of email. When user gets the email and clicks on the link script gets executed on the system and will become active when user enters the credentials to get into the site. Script captures the credentials and post those details to the hacker site behind the scene. Some times attackers uses URL encoding/ UTF encoding / ASCII representation of the URL parameters so user think it as a genuine data and clicks the URL.

NEVER click the bank URLs coming in the email. Generally bank's don't send there site URL in the emails.

I liked the White Paper which talks about this attack in detail. It talks about how these attacks are exploited and what can be done to prevent these attacks. You can also visit XSS Faqs section for further reading.

Google also had the XSS vulnerability which was fixed earlier this year.

Technorati : XSS

SAML in Action

Today I was browsing the net to find more on SAML and came across a good implementation of SAML by google. In this post I am going detailed out my understanding of SAML implementation by google.

Security Assertion Markup Language(SAML): It is used in a federated environment where TRUST is needed between service provider (like google gmail, gtalk etc) and identity provider (any organization using google applications). Google is providing it's services like gmail, gtalk etc for enterprises who wants to use these applications with there corporate domain. To enable these services and provide Single Sign On between corporate network and google application network SAML can be used.

Below diagram shows four main entities used for SAML implementation

1. Actor : User using the application hosted at service provider


2. Service Provider : In this case Google exposing it's services like gmail, gtalk etc.


3. Identity Provider : Corporate using the google services.


4. Repository : Store for holding the user base for the identity provider.

Step By Step Flow of SAML in Action

1) User accesses the service hosed by the service provider. There could be two different scenarios

a) User is already authenticated at the corporate (identity provider) :If user is already authenticated, identity provider will set the session in the cookie. This cookie will be passed to the user when service provider redirects the user for SAML assertion. Identity provider will validate the cookie and pass the user information in the assertion to the service provider without asking user to enter the credentials.

b) User is directly accessing the service without logging into the corporate portal: If the user is accessing the service without logging into the corporate network user will be asked to enter the credentials when service provider request for an assertion at the identity provider.

2) Service Provider requests for an assertion: As we know that SAML request and SAML response (assertions) are sent using XML over HTTP/S, it is mandatory to define the XML structure in which service provider will request for the assertion and identity provider will respond with an assertion. Google has also defined such schema's. Google is also using the RSA/DSA key pair (public/private) to validate the assertion sent by the identity provider. Corporate using the SAML SSO needs to generate the key pair and register the public key with google assertion validator (This is the component residing at the service provider [in this case google] to extract the user information from the assertion).

3)Identity Provider generates and sends the assertion: Identity provider will authenticate the user based on two cases mentioned in step 1 and passes the userid to the service provider.

Since we can not pass directly XML documents as the request parameters (GET/POST) over HTTP it is required to encode the SAML request and SAML responses.

Samples of the SAML request/responses

SAML Request XML format

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="fpagejpkbhmddfodlbmnfhdginimekieckijbeei"
Version="2.0"
IssueInstant="2006-05-02T08:49:40Z"
ProtocolBinding="urn:oasis:names.tc:SAML:2.0:bindings:HTTP-Redirect"
ProviderName="google.com"
AssertionConsumerServiceURL="https://www.google.com/hosted/psosamldemo.net/acs"/>

Encoded Request passed to the identity provider

identity_provider.html?SAMLRequest=eJxdkE1PwzAMhs%2F9F1XubcM00IjWTQOEmDTQtA8O3NrEa7M1donTjZ9P2UAgrraf1489nn64Jj6CZ0uYi6tUihhQk7FY5WK7eUxGYjoZc%2BGaVs26UOMK3jvgEEc9iKzOnVx0HhUVbFlh4YBV0Go9e16oQSpV6ymQpkZE84dc7Nqign17KGtnzI5MUzrc1aayaB0cLOiD3ZcAVsTR649Wn9LDzB3MkUOBoS9JeZPI60QONnKkhrdqKN9EtPxedWfxcsE%2Fr%2FSvV3kZYvW02SyTFRjrQYdzyNEa8C89kYuKqGog1eRENGMGH3qle0LuHPg1%2BKPVsF0tclGH0LLKstPplP5CWU0cwGQt09erDDhKEUJWaBbZ5BPy1YRc&RelayState=http%3A%2F%2Fwww.google.com%2Fhosted%2Fpsosamldemo.net%2FDashboard

SAML Response Generated at the Identity provider

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
ID="hedangifkfodeigidaeijpdnfjkfbnegddealebo"
IssueInstant="2006-08-17T10:05:29Z"
Version="2.0">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>sJAWNV9VzT+CghjrHsJSXAY9DRk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>X9Fx4pFSOlI2byrLXBw8azq26xxdqeF7w1UfQtcZ5l7HfXfkq9Tp2w==</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>/KaCzo4Syrom78z3EQ5SbbB4sF7ey80etKII864WF64B81uRpH5t9jQTxeEu0ImbzRMqzVDZkVG9xD7nN1kuFw==</P>
<Q>li7dzDacuo67Jg7mtqEm2TRuOMU=</Q>
<G>Z4Rxsnqc9E7pGknFFH2xqaryRPBaQ01khpMdLRQnG541Awtx/XPaF5Bpsy4pNWMOHCBiNU0NogpsQW5QvnlMpA==</G>
<Y>VMoV//Oh7VytBbZVySNmVZevV1bw7vmJwx5hHszeR25bforBFA19nk+3ehg6SgUjWiXn7HsybemjRFs5x4+XFg==</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<Assertion ID="dojnoaponicbieffopfdecilinaepodfimmkpjij"
IssueInstant="2003-04-17T00:46:02Z"
Version="2.0">
<Issuer>https://www.opensaml.org/IDP </Issuer>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> demouser </NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
</Subject>
<Conditions NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2008-04-17T00:51:02Z"> </Conditions>
<AuthnStatement AuthnInstant="2006-08-17T10:05:29Z">
<AuthnContext>
<AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:Password </AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>

Technorati : SAML

Technorati : SAML

How to View cookies in browser

Often a times we have to test what cookies are set on the browser during testing a issue. Everyone has figured out there own way of doing this. I would like to share the way I do this during troubleshooting.

1) You can use javascript:document.cookie on the browser window to check the cookies. Problem with this is that the content of the page is gone and you have to reload the page to see the page content. Use second approach to solve this problem.

2) Alternate to this approach is to use the javascript ALERT as javascript:alert(document.cookie). If there are one or two cookies this is fine but if number of cookies are more then reading the alert box becomes a pain. Use third approach to overcome this problem.

3) Use javascript:alert(unescape(document.cookie).replace(/;/gi,"\n\n")) to get the cookies displayed separately.

RSA Conference 2007

I got an opportunity to attend RSA conference here in Savannah (Hilton Island). It was more of a partner oriented conference but they talked about there product line and gave some of the new features of the products which are going to come in the market in next fiscal year.

I attended seminars on following products:

1) Authentication Manager 7.1 (Will be in the market in Mar-Apr 2008)
This product main focus is on Strong Authentication (one time password using hardware and software tokens). Software token is the good feature where in if the person forgets to carry the hardware token he can get the software token using self service. User has to answer security questions and software token will be sent to the user on either SMS or in a email.

They are also working on putting the software in the mobile phones for generating the token instead of carrying the separate device.

While attending the conference I asked how the software works on the cell phone? Is it the same software for all the users or is it user specific? I know these are silly questions but I never hesitate to ask questions so I did. They told me that software is same for everyone but the SEED is person specific and they also told me that one SEED can be assigned to three devices at the max at a single point of time. For example same SEED can be given on persons cell phone and same can be used for the hardware token also.
More on Authentication Manager in later posts after I can recollect my understandings.

2) RSA Key Manager

This product helps in managing the symmetric and asymmetric keys in the organization. It can be either for RSA products or it can also be used to manage encryption keys for home grown applications.

3) File Security System

RSA wants every content to be written in a secure manner and should be accessed by authorized persons ONLY. That is the reason they accuired a company who were in this area. This software works for putting the file contents in a secure manner and you can protect whole folder. You can then assign persons who can access those files and folders in a secure manner.

4) Database security System

This product secures the content of the database at a column level.

I will talk more about the inside of these products in the comming postings so keep reading.

Federated Access Control

Generally I hate do a copy paste of the content from other sites but I liked this one a lot (because of cute animations) so thought of sharing the same with my friends watching my blog.

DSML Introduction

Directory Services Markup Language (DSML) provides a mechanism for accessing directory servers as XML document. It evolved with version 1.0 which just gave flexibility to read the directory servers but version 2.0 came with more flexibility. Using version 2.0 directory server entries can be updated.

DSML functionality is motivated by scenarios including:

1) Hand held device which does not have LDAP client.
2) Applicaion programs developed using XML tools and application needs to access LDAP.
3) A program needs to access a directory across the firewall and firewall does not allow LDAP ports.
Click on the below image to view the animation.

4) Integrating two different vendor directory servers.

Most of the existing directory server vendors support the DSML but it needs to be enabled explicitely. Below are some links specific to Sun DS.

How to enable DSML support

Accessing Directory using DSML

DSML tools are also available for integration with existing applications.

Technorati : dsml introduction

How to enable special character support on Sun Directory Server?

Organizations in today's world are spreaded across the globe and they want to have a support of all the character set in the applications so there user's can access them at any part of the globe in there local language.

To enable Special character support in Sun DS follow below steps

1) Login into the directory manager console
2) Open the instance on which you want to enable special character support
3) Go to Configuration Tab
4) Expend the plugins
5) Select "7 bit check" plugin and disable it. By default it is enabled.
6) Restart the server and now you are all set to dump special characters in the Directory Server.

Same activity can be done using the command line but I am not posting that part here.