single signon

aibarguen used Ask the Experts™
I've been asked by a client to implement single signon for our web site from their network. The preferred methods/configurations are these:
1) SSO should occur over https
2) SSO information should include a timestamp
3) Trust information of any sort should be encrypted
4) Timestamps are synchronized with and/or to within +/- 30 seconds *
5) Where reasonable it is preferred that users only have access to the trusted system via SSO and not by direct login
6) The following hash and encryption methods are supported:
C. SHA-1/SHA-256 (Hash)
D. MD5 (Hash, deprecated)
7)  we need to support /access LDAP version 3 or higher

My site is built in .net using Visual Studio, SQL Server 2008 database - all hosted by DiscountASP.  

I have NO experience in any of this and am very nervous. My questions are;
1.How do I access their LDAP?  I think via XML somehow.  Any good references for this?
2. If I convert sites to https, what code updates will I have to do? Does it mean recoding of all pages or does it mainly hit the config.sys file?
3. anyone have good links to start researching?

Thanks SO much for any help...
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®


HTML and  thank you!


thanks, i need it!
SSO is a hell of a subject. It means so many different things depending on the context, and there are no simple answers.

Check with your client what are his expectations from the way users will work.
There are 2 basic options with radically different solutions.

Option A: users authenticate on the client's network
This happens when your web site provides a business service and is accessed by the users from the customer's network.
In this case, they come to your web site already pre-authenticated and now you have to accept them, see who they are, and validate their entitlement to service. Option A requires investment in access management tools, customization and development on the customer's side.

Option B: users authenticate on your web site
This happens when you provide service to users who are primarily at home or on the road, or when the client cannot do his part as required from option A.
Usually, you will not be able to create an authenticated session that will be trusted by the customer's infrastructure and applications, although there are (expensive) ways to achieve this.
In this case, you don't have real SSO, but should synchronize the user base (and passwords) with your customer's directory.
Optionally, the customer deploys an Identity management server that is accessible by your application.
The customer ensures that the Identity server mirrors the user base and the login credentials, and your application queries the identity server for authentication and entitlement.

All of the encryption and timestamps you ask about is basic programming stuff to be solved AFTER the architecture is ironed out.

SSL should be transparent to your web site, unless you have code that redirects or creates internal links or uses AJAX, and has http used explicitly.



This is the scenario:
1. the trusted system will deliver a comma-delimited file nightly of authorized users
2. AES encryption method will be used and the appropriate keys swapped.  Note: encrypted values must also be base64 encoded for https transmission.
3 SSO must be implemented using https form POST

I understand how to do #1, #2 & 3 are little more vague.  Does anyone have examples of these in or html that I could see?  Thanks!
please describe what should in your opinion happen when the "SSO" kicks into action.


This is what my client has given me as far as procedure:

1. a file is sent nightly from my client with the names of the users permitted to access the app
2) User clicks on SSO link on the Inside client intranet (they have logged in to their network) that will link to my external site (let's call it ACME)
3) New browser window opens
4) In the new browser, a form is generated by the Inside pc
5) The form contains a source and a data tag. The value of the source tag identifies that it is the client. The value of the data tag is encrypted (and then base64 encoded) and contains:
a) A single-use token (randomly generated, alpha-numeric, of fixed length)
b) A timestamp (UTC/GMT eg “20070112T1714425Z”)
c) The unique user identifier (username or user id) on the ACME system
9) Upon receiving the form POST, the ACME web server recognizes that the sender is from the client site (from the source tag), which enables it to know which keys to use for decryption. It then base64 decodes and decrypts the data tag, wherein it finds the single-use token, the timestamp and the username.
10) The ACME web server then validates that the timestamp has not expired (typically within +/-30 seconds)
11) The ACME web server also validates the username with the client server, via a web service.
12) If  the timestamp validates successfully, and the username is a valid user on the ACME system, then the ACME web server logs in the user and renders the web page it usually shows to users who have just logged in successfully

I will be forever grateful if I could figure this out!  

how do you plan to use the token? will it be used to authenticate your server to the web service?

synching your server's time with reliable time providers:

BASE64 transformation

AES is a symmetric encryption, so I assume that you will swap keys beforehand in a secure manner.

there are still a few major unknowns.
How does the customer plan for you to have the daily file in a secure manner?
The customer must deploy a web service to verify users. This web service will hide the LDAP details from you, so you will not have to deal directly with LDAP.
Of course, you need the web service details..


Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial