SingleSignOn Work Item Rss Feed

CLOSED ISSUE: Better Session Maintenance

nlb6665 — Mon, 31 Mar 2008 17:36:26 GMT

Currently the server-side doesn't clean up after itself and old sessions remain. I'll probably build a better security factor in to expire old sessions and/or delete them.
Comments: 2.0 beta

CLOSED ISSUE: Web Service Security

nlb6665 — Mon, 31 Mar 2008 17:36:03 GMT

---------edited Aug 14, 2007--------
I've decided to implement another form of security using a shared key. It's a custom solution and only recommended for Medium Trust shared hosting solutions. For Full Trust solutions WSE 3.0 or WCF should be used instead.

There will be a server side admin tool for the keys. A separate key should be generated for each client machine. The key will be saved as a key file in the client application folder (or location of your choice), then it will be read and passed to each web service call for validation. (just like the current solution). The only difference is the key isn't dynamically generated and authenticated with a username/password.

This prevents the keys from never expiring like they did before and, you can expire keys on the server side in case one becomes compromised.

-----Edited Sept 8, 2007-----
I'm working on posting these changes now. Feel free to comment on the discussion thread. The old release will still be available with the session based web service security.

Thoughts?
Discussion thread: http://www.codeplex.com/SingleSignOn/Thread/View.aspx?ThreadId=13798

CLOSED FEATURE: Dynamic Mode Security - Add user authorization to function calls

nlb6665 — Mon, 31 Mar 2008 17:33:53 GMT

Basically once a service key is validated the client application has free reign against the membership functions. This is fine for a web application in most cases because it's running on a trusted host. However, in a windows forms situation, your key is being sent directly to a user so their application can talk to your membership service. I think there should be an optional way to lock down the membership functions for untrusted applications. I've been thinking about a way to maybe lock it down by authorized groups. That way say minimal users would only be able to login and obtain their groups, maybe reset a password. More privileged users could do more.

thoughts?
Comments: in 2.0 beta

REOPENED FEATURE: Dynamic Mode Security - Add user authorization to function calls

nlb6665 — Mon, 31 Mar 2008 17:33:36 GMT

CLOSED FEATURE: Dynamic Mode Security - Add user authorization to function calls

nlb6665 — Mon, 31 Mar 2008 17:33:06 GMT

CREATED FEATURE: Dynamic Mode Security - Add user authorization to fucntion calls

nlb6665 — Sat, 29 Mar 2008 06:36:13 GMT

CREATED ISSUE: Personalization/Profiles

nlb6665 — Tue, 27 Nov 2007 22:29:13 GMT

I noticed the other day that profiles and personalization were a neat piece that could work well in this. So heres' a little work item to make those objects available via web services which would enable inter-site personalization settings. I found when trying to enable web parts.

CREATED ISSUE: App still redirecting to login page after logging into SSOSite

nlb6665 — Wed, 17 Oct 2007 13:40:53 GMT

Basically this is is a work item for creating shared session functionality between AppDomains. So you can essentially login to one web application and automatically already be authenticated for another web application using the same SingleSignOn authentication service.

Links with more info
This page http://weblogs.asp.net/scottgu/archive/2005/12/10/432851.aspx explains how to share the authentication cookie.

COMMENTED ISSUE: Feature requests: Password expiration, Account inactivity expiration and password history

nlb6665 — Sun, 23 Sep 2007 03:21:47 GMT

Hi,

I want to describe some feature request, which i would also like to contribute for in the next future.
I only want some feedback for coding and realization.

Feature request 1: password expiration
- In the standard Membership, is it not possible to let a passwort expire after some time (e.g. 3 months, 100 days or 1000 hours)

Feature request 2: user lock out after inactivity
- it is useful and sometimes necessary to lock out a user automtically if he/she is inactive for some time (e.g. 3 months)

Feature request 2: password history
- some security guidelines need a password history for the last 6 or 8 password, so
that the user don't "reuse" their in short periods

Any feedback is appreciate!

regards
Christian
Comments: ** Comment from web user: nlb6665 **

I'll create an open issue for this one. I'm not sure how quick I can get to it, but if you have some code that works with this, I'd be happy to integrated it.

Thanks!
-Nathan

CREATED ISSUE: Feature requests: Password expiration, Account inactivity expiration and password history

nlb6665 — Sun, 23 Sep 2007 03:21:07 GMT

COMMENTED ISSUE: Better Session Maintenance

nlb6665 — Wed, 12 Sep 2007 13:49:48 GMT

Currently the server-side doesn't clean up after itself and old sessions remain. I'll probably build a better security factor in to expire old sessions and/or delete them.
Comments: ** Comment from web user: nlb6665 **

This has been removed due to the recent security change. There is no longer a web service database session.

COMMENTED ISSUE: Web Service Security

nlb6665 — Mon, 10 Sep 2007 18:52:59 GMT

---------edited Aug 14, 2007--------
I've decided to implement another form of security using a shared key. It's a custom solution and only recommended for Medium Trust shared hosting solutions. For Full Trust solutions WSE 3.0 or WCF should be used instead.

There will be a server side admin tool for the keys. A separate key should be generated for each client. The key will be saved as a key file in the client application folder (or location of your choice), then it will be read and passed to each web service call for validation. (just like the current solution). The only difference is the key isn't dynamically generated and authenticated with a username/password.

-----Edited Sept 8, 2007-----
I'm working on posting these changes now. Feel free to comment on the discussion thread. The old release will still be available with the session based web service security.

Thoughts?
Discussion thread: http://www.codeplex.com/SingleSignOn/Thread/View.aspx?ThreadId=13798
Comments: ** Comment from web user: nlb6665 **

Check out the latest release.

CREATED ISSUE: Better Session Maintenance

nlb6665 — Mon, 02 Jul 2007 23:53:31 GMT

Currently the server-side doesn't clean up after itself and old sessions remain. I'll probably build a better security factor in to expire old sessions and/or delete them.

COMMENTED ISSUE: Web Service Security

Heynemann — Tue, 12 Jun 2007 13:42:52 GMT

I have a few ideas to improve the web service security. Right now it's a manual login process that generates a randomized session key. The only way to get a key is to login and the only way to invoke a web service is to have a key. The problem is, there's no built-in expiration or a way to tell the membership provider to re-initialize after expiring a session (there's probably a better way to do it all anyways). I'm thinking about using a public/private key encryption and SOAP Extensions to encrypt the data channels between the service and client. By doing that, only applications with public keys will be able to communicate with the web services. Then there wouldn't be a need for generating sessions. I'm still considering other options as well. Thoughts? Comments: ** Comment from web user: Heynemann **

Not at all. You could use the Isolated Storage are for the user to keep an encrypted xml file containing the user and password. I´ll be doing some work on the Service infra-structure of this project soon. Probably I´ll do the services in WCF since it allows for security between parties already.

CLOSED TASK: Windows Forms Client Sample

nlb6665 — Tue, 12 Jun 2007 05:50:40 GMT

I'm planning on pushing out a sample windows form client application to show how this would work. This task is kind of dependent on the security issue. The windows client sample is basically just a windows forms app that communicates with its own instance of the membership provider. In this case a WebServiceMemebershipProvider from the SingleSignOn library. This library will then communicate with a central website and authenticate users.

COMMENTED TASK: Windows Forms Client Sample

nlb6665 — Tue, 12 Jun 2007 05:50:17 GMT

Check current release.

COMMENTED TASK: Windows Forms Client Sample

caldarola — Mon, 04 Jun 2007 10:36:22 GMT

I'm very interested to this issue.

CREATED ISSUE: Windows Forms Client Sample

nlb6665 — Sun, 03 Jun 2007 01:51:57 GMT

COMMENTED ISSUE: Web Service Security

nlb6665 — Fri, 01 Jun 2007 14:57:07 GMT

I also realize that this is kind of a big security issue with windows forms clients. The service username and password would have to be in the app.config.

CREATED ISSUE: Web Service Security

nlb6665 — Tue, 29 May 2007 16:12:42 GMT

I have a few ideas to improve the web service security. Right now it's a manual login process that generates a randomized session key. The only way to get a key is to login and the only way to invoke a web service is to have a key. The problem is, there's no build-in expiration yet or a way to tell the membership provider to re-initialize after expiring a session and there's probably a better way to do it all anyways. I'm thinking about using a public/private key encryption and SOAP Extensions to encrypt the data channels between the service and client. By doing that, only applications with public keys will be able to communicate with the web services. Then there wouldn't be a need for generating sessions. Thoughts?