SingleSignOn Release Rss Feed

Reviewed: SingleSignOn 2.0 Beta (Dec 04, 2008)

vijaykarla — Thu, 04 Dec 2008 13:40:19 GMT

Rated 3 Stars (out of 5) - Trying to iplement this idea ;-)

UPDATED RELEASE: SingleSignOn 2.0 Beta (Mar 28, 2008)

Mon, 31 Mar 2008 17:35:11 GMT

***Please report any bugs and feature requests in the issue tracker***
[url:/SingleSignOn/WorkItem/List.aspx]

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So any application using this shares its application name with the host application. Also, defining encryption, etc won't work because it relies on the server-side configuration for the SqlMembershipProvider. Since flat text is transmitted between the client applications and the server, you should use transport encryption (SSL/HTTPS) to protected your information. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side; I'll look into that so I can understand what's going on.

More documentation coming soon!

Source code includes Visual Studio 2005 and 2008 solutions

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0 Beta (Mar 28, 2008)

Mon, 31 Mar 2008 17:34:51 GMT

***Please report any bugs and feature requests with the code or documentation in the issue tracker***
[url:/SingleSignOn/WorkItem/List.aspx]

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So any application using this shares its application name with the host application. Also, defining encryption, etc won't work because it relies on the server-side configuration for the SqlMembershipProvider. Since flat text is transmitted between the client applications and the server, you should use transport encryption (SSL/HTTPS) to protected your information. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side; I'll look into that so I can understand what's going on.

More documentation coming soon!

Source code includes Visual Studio 2005 and 2008 solutions

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0 Beta (Mar 28, 2008)

Sat, 29 Mar 2008 05:56:43 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So any application using this shares its application name with the host application. Also, defining encryption, etc won't work because it relies on the server-side configuration for the SqlMembershipProvider. Since flat text is transmitted between the client applications and the server, you should use transport encryption (SSL/HTTPS) to protected your information. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side; I'll look into that so I can understand what's going on.

More documentation coming soon!

Source code includes Visual Studio 2005 and 2008 solutions

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0 Beta (Mar 28, 2008)

Fri, 28 Mar 2008 18:12:07 GMT

UPDATED RELEASE: SingleSignOn 2.0 Beta (Mar 28, 2008)

Fri, 28 Mar 2008 14:29:39 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So Application Name, defining encryption, etc won't work in this. You'll have to define those on the server side and rely on transport encryption (SSL/HTTPS) to lock down your transmissions. I would like to build a better solution for handling multiple application names in the future. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side.

More documentation coming soon!

Source code includes Visual Studio 2005 and 2008 solutions

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0 Beta (Mar 28, 2008)

Fri, 28 Mar 2008 14:28:45 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So Application Name, defining encryption, etc won't work in this. You'll have to define those on the server side and rely on transport encryption (SSL/HTTPS) to lock down your transmissions. I would like to build a better solution for handling multiple application names in the future. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side.

More documentation coming soon!

Source code includes Visual Studio 2005 and 2008 solutions

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0 Beta

Fri, 28 Mar 2008 05:37:26 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So Application Name, defining encryption, etc won't work in this. You'll have to define those on the server side and rely on transport encryption (SSL/HTTPS) to lock down your transmissions. I would like to build a better solution for handling multiple application names in the future. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side.

More documentation coming soon!

Source code includes Visual Studio 2005 and 2008 solutions

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0 Beta

Fri, 28 Mar 2008 05:32:04 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So Application Name, defining encryption, etc won't work in this. You'll have to define those on the server side and rely on transport encryption (SSL/HTTPS) to lock down your transmissions. I would like to build a better solution for handling multiple application names in the future. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side.

More documentation coming soon!

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0 Beta

Fri, 28 Mar 2008 05:20:44 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So Application Name, defining encryption, etc won't work in this. You'll have to define those on the server side and rely on transport encryption (SSL/HTTPS) to lock down your transmissions. I would like to build a better solution for handling multiple application names in the future. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side.

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0.0

Fri, 28 Mar 2008 05:19:56 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So Application Name, defining encryption, etc won't work in this. You'll have to define those on the server side and rely on transport encryption (SSL/HTTPS) to lock down your transmissions. I would like to build a better solution for handling multiple application names in the future. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side.

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0.0

Thu, 27 Mar 2008 05:58:45 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* is the web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* is the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So Application Name, defining encryption, etc won't work in this. You'll have to define those on the server side and rely on transport encryption (SSL/HTTPS) to lock down your transmissions. I would like to build a better solution for handling multiple application names in the future. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side.

Stay tuned!

UPDATED RELEASE: SingleSignOn 2.0.0

Thu, 27 Mar 2008 05:57:23 GMT

This is not a huge departure from what I had before, but it is significant enough that I decided to change the major version. This release will include a host of changes, bug fixes, and improvements. Please bare with me while I clean it up for a release. You can get the current code from the Source Code tab under the /trunk. I'll leave the old 1.1.0 release out here and you can see its source code under /tags/1.1.0 in the Source Code tab.

Changes include: {**Incomplete**}
*Server-side and client-side library separation - no more reference.cs file getting messed up when updating the web references
*Initialization handled using the built in initialization method. Now settings appear as attributes on the provider configuration vs a custom settings config section.
*numerous bug fixes that I've found by using this library.
*Synchronized my private library with the codeplex one. You get what I'm using.
*Built an optional Dynamic or Static service key. So now you can have a windows app that generates a key session and a web app that uses a static file.

Definitions:
*Client-side* means web site or windows forms application that consumes these web services to access membership from a central server.
*Server-side* means the actual web site that hosts the web services providing the membership information.

Some caveats should be mentioned. This library is literally a passthrough to a server side membership provider. So Application Name, defining encryption, etc won't work in this. You'll have to define those on the server side and rely on transport encryption (SSL/HTTPS) to lock down your transmissions. I would like to build a better solution for handling multiple application names in the future. Also... all provider names server and client-side have to be the same name if you want to use the ASP.NET configuration tool on the client-side.

Stay tuned!

UPDATED RELEASE: SingleSignOn 1.1.0 (Sep 10, 2007)

Sun, 16 Sep 2007 23:44:43 GMT

This release completely replaces the old session security with a new key based security. I'm hoping it will be easier to manage and potentially more secure. It's open ended so anyone using this code is encouraged to create your own security models, use WCF, or change the management piece.

The default package includes a predefined key that you can use with the test programs as an example. I highly recommend changing that key if you use this outside a developer environment. I'll have more docs, instructions, etc to go along with this release as I complete them.

Feed back on this release is much appreciated. Please let me know in the discussions if you find anything buggy.

I'll have instructions for this release coming soon. I just wanted to get it out there so people could check it out.

Thanks,
-Nathan

*Update*
Okay, I messed up deploying this. I just replaced it with a new solution file so you don't get prompted to remove the source control bindings. If you still get it, just click, "Remove Bindings" or re-download this release. My apologies.

*Instructions*
Download and extract the release source. Open the solution file. Compile the code to make sure it builds. Select the Website project "SSOSite" and toggle its "Use dynamic ports" to false and set the port to 1388. Set your startup project to be either of the test client projects "SSOTestSite" or "TestWindowsClient." Then run the client. You should be able to login successfully with testuser or testadmin, both with password: testpass#

To run the admin tool, just set your startup project to be SSOSite and login to the admin site using testadmin. The admin site is a very quick and dirty solution to give you a little management site for your users. Feel free to make any necessary changes for your specific situation.

*Security Setup*
It's recommend that each application on each machine have its own security key file. So, to setup a new client, login to the admin site and go to the Service security screen. Create a new key file by clicking the Create Registration link at the top of the list. Enter an expiration date for the new key and click Save. This will refresh the list and show your new key. Click Download Key to download the key file and save it to your client application directory. You'll now need to setup your web service configuration to use the new key file by editing your app.config or web.config file. Create a new appsetting named "WebServiceKeyFile" with a value of the path to the key file. You can use "~/" for web applications or "@/" for paths relative to the executable. (I think this uses System.Windows.Forms.Application.ExecutablePath). Once you have the client setup with the key file, you can test it by logging in. (Also do not forget to setup your system.web.security settings to use the security provider model. Otherwise none of this will work. Take a look at the sample application config files to see more details.

Let me know if you have any questions. Just drop a line in the discussions.

Thanks

UPDATED RELEASE: SingleSignOn 1.1.0 (Sep 10, 2007)

Sun, 16 Sep 2007 23:42:39 GMT

This release completely replaces the old session security with a new key based security. I'm hoping it will be easier to manage and potentially more secure. It's open ended so anyone using this code is encouraged to create your own security models, use WCF, or change the management piece.

The default package includes a predefined key that you can use with the test programs as an example. I highly recommend changing that key if you use this outside a developer environment. I'll have more docs, instructions, etc to go along with this release as I complete them.

Feed back on this release is much appreciated. Please let me know in the discussions if you find anything buggy.

I'll have instructions for this release coming soon. I just wanted to get it out there so people could check it out.

Thanks,
-Nathan

*Update*
Okay, I messed up deploying this. I just replaced it with a new solution file so you don't get prompted to remove the source control bindings. If you still get it, just click, "Remove Bindings" or re-download this release. My apologies.

*Instructions*
Download and extract the release source. Open the solution file. Compile the code to make sure it builds. Select the Website project "SSOSite" and toggle its "Use dynamic ports" to false and set the port to 1388. Set your startup project to be either of the test client projects "SSOTestSite" or "TestWindowsClient." Then run the client. You should be able to login successfully with testuser or testadmin, both with password: testpass#

To run the admin tool, just set your startup project to be SSOSite and login to the admin site using testadmin. The admin site is a very quick and dirty solution to give you a little management site for your users. Feel free to make any necessary changes for your specific situation.

*Security Setup*
It's recommend that each application on each machine have its own security key file. So, to setup a new client, login to the admin site and go to the Service security screen. Create a new key file by clicking the Create Registration link at the top of the list. Enter an expiration date for the new key and click Save. This will refresh the list and show your new key. Click Download Key to download the key file and save it to your client application directory. You'll now need to setup your web service configuration to use the new key file by editing your app.config or web.config file. Create a new appsetting named "WebServiceKeyFile" with a value of the path to the key file. You can use "~/" for web applications or "@/" for paths relative to the executable. (I think this uses System.Windows.Forms.Application.ExecutablePath). Once you have the client setup with the key file, you can test it by logging in. (Also do not forget to setup your system.web.security settings to use the security provider model. Otherwise non of this will work. Take a look at the sample application config files to see more details.

Let me know if you have any questions. Just drop a line in the discussions.

Thanks

UPDATED RELEASE: SingleSignOn 1.1.0 (Sep 10, 2007)

Sun, 16 Sep 2007 23:41:15 GMT

This release completely replaces the old session security with a new key based security. I'm hoping it will be easier to manage and potentially more secure. It's open ended so anyone using this code is encouraged to create your own security models, use WCF, or change the management piece.

The default package includes a predefined key that you can use with the test programs as an example. I highly recommend changing that key if you use this outside a developer environment. I'll have more docs, instructions, etc to go along with this release as I complete them.

Feed back on this release is much appreciated. Please let me know in the discussions if you find anything buggy.

I'll have instructions for this release coming soon. I just wanted to get it out there so people could check it out.

Thanks,
-Nathan

*Update*
Okay, I messed up deploying this. I just replaced it with a new solution file so you don't get prompted to remove the source control bindings. If you still get it, just click, "Remove Bindings" or re-download this release. My apologies.

*Instructions*
Download and extract the release source. Open the solution file. Go ahead and compile to make sure it builds. Select the Website project "SSOSite" and toggle it's "Use dynamic ports" to false and set it to 1388. Set your startup project to be either of the test client projects "SSOTestSite" or "TestWindowsClient." Then run the client. You should be able to login successfully with testuser or testadmin, both with password: testpass#

To run the admin tool, just set your startup project to be SSOSite and login to the admin site using testadmin. The admin site is a very quick and dirty solution to give you a little management site for your users. Feel free to make any necessary changes for your specific situation.

*Security Setup*
It's recommend that each application on each machine have its own security key file. So, to setup a new client, login to the admin site and go to the Service security screen. Create a new key file by clicking the Create Registration link at the top of the list. Enter an expiration date for the new key and click Save. This will refresh the list and show your new key. Click Download Key to download the key file and save it to your client application directory. You'll now need to setup your web service configuration to use the new key file by editing your app.config or web.config file. Create a new appsetting named "WebServiceKeyFile" with a value of the path to the key file. You can use "~/" for web applications or "@/" for paths relative to the executable. (I think this uses System.Windows.Forms.Application.ExecutablePath). Once you have the client setup with the key file, you can test it by logging in. (Also do not forget to setup your system.web.security settings to use the security provider model. Otherwise non of this will work. Take a look at the sample application config files to see more details.

Let me know if you have any questions. Just drop a line in the discussions.

Thanks

UPDATED RELEASE: SingleSignOn 1.1.0 (Sep 10, 2007)

Fri, 14 Sep 2007 03:00:34 GMT

UPDATED RELEASE: SingleSignOn 1.1.0 (Sep 10, 2007)

Fri, 14 Sep 2007 02:59:39 GMT

UPDATED RELEASE: SingleSignOn 1.1.0 (Sep 10, 2007)

Sun, 09 Sep 2007 23:29:54 GMT

RELEASED: SingleSignOn 1.1.0 (Sep 10, 2007)

Sun, 09 Sep 2007 23:29:54 GMT