Daily Archives

Articles indexed Monday December 6 2010

Page 19/22 | < Previous Page | 15 16 17 18 19 20 21 22  | Next Page >

• Welcome to my first official full time employee!

  - by Vizioz Limited

  The last few months have been pretty manic and Vizioz has been growing successfully into a fully fledged development agency. I have been working with a couple of excellent off shore developers who I would like to publicly thank for all their hard work over the last couple of months!This week has been the start of a new era for Vizioz, I have taken on my first full time developer who is now based in our office in Reading, welcome to Colin. Which means we now have 3 Umbraco developers! Currently one with Level 2 qualification (me) but if business keeps growing I'll be sending the others for training shortly so hopefully by the end of the summer we'll be a certified solution provider.We have lots of plans for the next 6 months, so it should be exciting times, subscribe to my RSS feed to come along for the ride :)

  Read the article

• Using the Windows Explorer Context Menu to reset Umbraco Directory Permissions

  - by Vizioz Limited

  Hi All,As Umbraco matures I am assuming that needing to reset directory permissions might well become a thing of the past, but at the moment it is still something when I copy sites between machines that I often find myself doing.As it's 4:30am I thought, there must be a better way than having to open up a DOS prompt, navigate to a directory and then run a batch file passing in the IIS root folder location.Well.. there is :)I googled for adding a command to the context menu within Windows Explorer, I found a way of doing this for XP, but it seems the functionality was removed from Windows 7, however I found a very neat freeware application called File Menu Tools which does work perfectly!I have now added a command to my context menu that enables me to right click an IIS site root folder and then call my batch script and automatically pass in the directory.This will save me a bunch of time :)

  Read the article

• Umbraco Developer 's Christmas Office :)

  - by Vizioz Limited

  This weekend my colleague and I decided it was a good idea to decorate our office for Christmas, it's quite difficult to actually photograph it to it's full effect, but you'll have to take our word for it, it looks pretty Christmasy :) We have a 7' Tree covered in lights and decorations, lights around our PC's, tinsel everywhere we could fit it, and even large snow flakes hanging from the ceiling..You'd think we have no work on, but if fact it's the opposite we're manically busy! But hey, it's a bit of fun and it seems to be cheering everyone up in this otherwise rather Dull Regus Serviced Office ;-)We can definitely recommend doing something a bit different, as it's got us noticed and we've already won enough extra work from companies in the building to pay for our office for a year, not bad :)So here's a photo of our office, has anyone else decorated their office? I'd be happy to update this post with any good Christmas office photos that you send me!Happy Christmas all!Chris

  Read the article

• Add Intellisense when using the URL rewritingnet config file

  - by Vizioz Limited

  I often use the URL re-writing engine that comes with Umbraco which is from urlrewriting.net and I have always found it very fiddly to edit the configuration file, I wish I have know it was possible to add Intellisense to Visual Studio, and I guessed that most people would also not realise this, after all, who reads the manual right?!So, if you are someone who edits the urlrewriting.config without Intellisense, but would like to use it, this is how you do it :)1) Download the URL rewriting source code files from urlrewriting.net2) Unzip the source files and find the urlwritingnet.xsd file, put this file into your web project, or the directory where your urlredirect.config lives.3) Open up the web project and then open your config file, and hey presto! You should find you now have intellisense!So, the next question is, are there XSD files for the rest of the Umbraco config files, and more importantly for the Umbraco.xml file? If not, does anyone fancy creating them? I am sure intellisense for all these files would be very helpful :)

  Read the article

• Twitter Feeds in Umbraco using XSLT

  - by Vizioz Limited

  There are currently two packages tagged on the Umbraco forum that can be used to add a twitter feed to your website. I was playing around with "Twitter for Umbraco" by Warren Buckley and noticed a bug in the way it converted twitter @names to links, so I thought I would try and solve this using XSLT.It may also be useful for those of you using Darren Ferguson's "Feed Cache" package as the demo on Darren's site does not add links to the tweets.To use this XSLT you simple call the XSLT Template passing in your Twitter message:<xsl:call-template name="formaturl"> <xsl:with-param name="url" select="text"/></xsl:call-template>Then add the XSLT template to your XSLT macro (outside of the main template)<xsl:template name="formaturl"> <xsl:param name="twitterfeed"/> <xsl:variable name="transform-http" select="Exslt.ExsltRegularExpressions:replace($twitterfeed, '(http\:\/\/\S+)',ig,'<a href="$1">$1</a>')"/> <xsl:variable name="transform-https" select="Exslt.ExsltRegularExpressions:replace($transform-http, '(HTTps\:\/\/\S+)',ig,'<a href="$1">$1</a>')"/> <xsl:variable name="transform-AT" select="Exslt.ExsltRegularExpressions:replace($transform-https, '(^|\s)@(\w+)',ig,' <a href="http://www.twitter.com/$2">@$2</a>')"/> <xsl:variable name="transform-HASH" select="Exslt.ExsltRegularExpressions:replace($transform-AT, '(^|\s)#(\w+)',ig,' <a href="http://www.twitter.com/search?q=$2">#$2</a>')"/> <xsl:value-of select="$transform-HASH" disable-output-escaping="yes"/> </xsl:template>You should find that this now replaces all the @names, #names and URL's with links!

  Read the article

• Survey about Umbraco Repositories

  - by Vizioz Limited

  I am currently thinking about developing a hosted repository service for Umbraco Packages, this will allow free, private and commercial repositories to be available within the Umbraco interface for immediate installation.I would be really interested to hear your views and opinions on this sort of service:Please answer this survey!Everyone who answers the survey and leaves their email address will be sent an invitation to beta test the service when it launches in the near future :)

  Read the article

• Umbraco Permissions Script - Secure Version

  - by Vizioz Limited

  Back in May I blogged about how to set Permissions for Umbraco using SetACL to set the appropriate directory permissions based on the installation recommendations.Recently I have been working on a site for a client who wanted every security item to be locked down as tightly as possible. And so I modified the script based on the Umbraco security best practices, I thought I'd share it with everyone, if I have missed anything, or if anyone has any suggestions on how to improve this, please let me know :)Please refer to my previous post regarding the SetAcl command line application that you will need.I suggest you save the following into a batch file called: umbPermSecure.batecho offREM Script to setup the Security Permissions for an Umbraco siteREM This script will give your machine Network Service the minimum rights requiredREM for Umbraco to workREM I suggest you update this script to also remove any users who do not need REM access to the web foldersREM **** Pre-requisites ****REM You will need to download - http://setacl.sourceforge.net/REM It is assumed that you have stored SetACL in a directory called, C:\SetACL ifREM not, you will need to modify the script.REM **** Usage ****REM You need to pass in the path for the root of your Umbraco directoryREM E.g. umbPermSecure.bat C:\inetpub\umbracoroot@echo umbPermSecure.bat - Script to set Umbraco File and Directory Permissions@echo based on the Umbraco Security Best Practices Document (13th March 2009)@echo Published by Chris Houston - 19th October 2009@echo http://blog.vizioz.com@echo Adding READ only access SetACL.exe -on "%1" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\web.config" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\bin" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\umbraco" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"@echo Adding READ and EXECUTE access SetACL.exe -on "%1\app_code" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read_ex" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\usercontrols" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read_ex" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"@echo Adding READ, WRITE and MODIFY access SetACL.exe -on "%1\config" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -ace "n:%computername%\NETWORK SERVICE;p:change" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\css" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -ace "n:%computername%\NETWORK SERVICE;p:change" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\data" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -ace "n:%computername%\NETWORK SERVICE;p:change" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\masterpages" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -ace "n:%computername%\NETWORK SERVICE;p:change" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\media" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -ace "n:%computername%\NETWORK SERVICE;p:change" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\python" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -ace "n:%computername%\NETWORK SERVICE;p:change" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\scripts" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -ace "n:%computername%\NETWORK SERVICE;p:change" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"SetACL.exe -on "%1\xslt" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:read" -ace "n:%computername%\NETWORK SERVICE;p:change" -actn clear -clr "dacl,sacl" -log "c:\setacl\log.txt"

  Read the article

• Umbraco Certified Developer - Level 2 - Chris Houston

  - by Vizioz Limited

  I just thought I'd create a quick blog post to say that I have now been on the Umbraco Level 2 course (which I would recommend!) and although it turned out that I pretty much new 95% of what was taught, the extra 5% and a chance to have a trip to Copenhagen made it worth it :)I am now officially Umbraco level 2 certified :)Hopefully over the next month I will have some time to start adding a few more useful blog posts to my blog. I know I've been a little slack on the posting in the last month, it's just been a busy time for me!

  Read the article

• How to add items to the Document Types context menu.

  - by Vizioz Limited

  I am currently working on an extension to Umbraco that needed an extra menu item on the Document Types menu in the Settings section, my first thought was to use the BeforeNodeRender event to add the menu item, but this event only fires on the Content and Media menu trees.See: Codeplex Issue 21623The "temporary" solution has been to extend the "loadNodeTypes" class, I say temporary because I assume that the core team may well extend the event functionality to the entire menu tree in the future which would be much better and would prevent you from having to complete override the menu items.This was suggested by Slace on my "is it possible to add an item to the context menu in tree's other than media content" post on the our.umbraco.org site.There are three things you need to do:1) Override the loadNodeTypesusing System.Collections.Generic;using umbraco.interfaces;using umbraco.BusinessLogic.Actions;namespace Vizioz.xMind2Umbraco{ // Note: Remember these menu's might change in future versions of Umbraco public class loadNodeTypesMenu : umbraco.loadNodeTypes { public loadNodeTypesMenu(string application) : base(application) { } protected override void CreateRootNodeActions(ref List<IAction> actions) { actions.Clear(); actions.Add(ActionNew.Instance); actions.Add(xMindImportAction.Instance); actions.Add(ContextMenuSeperator.Instance); actions.Add(ActionImport.Instance); actions.Add(ContextMenuSeperator.Instance); actions.Add(ActionRefresh.Instance); } protected override void CreateAllowedActions(ref List<IAction> actions) { actions.Clear(); actions.Add(ActionCopy.Instance); actions.Add(xMindImportAction.Instance); actions.Add(ContextMenuSeperator.Instance); actions.Add(ActionExport.Instance); actions.Add(ContextMenuSeperator.Instance); actions.Add(ActionDelete.Instance); } }}2) Create a new Action to be used on the menuusing umbraco.interfaces;namespace Vizioz.xMind2Umbraco{ public class xMindImportAction : IAction { #region Implementation of IAction public static xMindImportAction Instance { get { return umbraco.Singleton<xMindImportAction>.Instance; } } public char Letter { get { return 'p'; } } public bool ShowInNotifier { get { return true; } } public bool CanBePermissionAssigned { get { return true; } } public string Icon { get { return "editor/OPEN.gif"; } } public string Alias { get { return "Import from xMind"; } } public string JsFunctionName { get { return "openModal('dialogs/xMindImport.aspx?id=' + nodeID, 'Publish Management', 550, 480);"; } } public string JsSource { get { return string.Empty; } } #endregion }}3) Update the UmbracoAppTree table, my case I changed the following:TreeHandlerTypeFrom: loadNodeTypesTo: loadNodeTypesMenuTreeHandlerAssemblyFrom: umbracoTo: Vizioz.xMind2UmbracoAnd the result is:

  Read the article

• Regular expression in Umbraco for number validation.

  - by Vizioz Limited

  This evening I was looking for a way to validate an Umbraco node that could be either text or a numeric value, in my case a salary that could be either an hourly amount, an annual figure or a comment. In the case where the node contained a value I wanted the XSLT to output a pound sign (£) and for any that contained text it would just output the text, as this could be something like "Contact Us" or "Negotiable"I thought someone else might find this useful so here is the XSLT and the regular expression.First if you are using Umbraco, don't forget to include the reference to the EXSLT Regular expression library at the top of your XSLT.<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxml="urn:schemas-microsoft-com:xslt" xmlns:umbraco.library="urn:umbraco.library" xmlns:Exslt.ExsltRegularExpressions="urn:Exslt.ExsltRegularExpressions" exclude-result-prefixes="msxml umbraco.library Exslt.ExsltRegularExpressions">Then the code I used was:<xsl:if test="Exslt.ExsltRegularExpressions:match($currentPage/data [@alias='Salary'], '^[0-9]*\,?[0-9]*\.?[0-9]+$') != ''"> <xsl:text>£</xsl:text></xsl:if>This regular expression allows any number of digits, an optional comma, more digits, an optional decimal point and finally more digits, so all the following are valid:12,00014.43334,342.03

  Read the article

• Umbraco directory permissions | umbPermissions Script

  - by Vizioz Limited

  It has bugged me since I first used Umbraco that if I was doing a manual installation I had to set the directory permissionsI just downloaded a backup of one of my clients Umbraco sites and I was setting up a copy locally and of course I had to set the directory permissions, so I thought there must be a better way!I did a bit of Googling and had a look on the Umbraco forum but I could not find a script to perform this task, then I came across Set ACL on Source Forge and I set about writing my own little script.Save the following script as umbpermissions.bat and save it in the same directory as Set ACLecho offREM Script to setup the Security Permissions for an Umbraco siteREM This script will give your machine Network Service full rights to the appropriate directoriesREM **** Pre-requisites ****REM You will need to download - http://setacl.sourceforge.net/REM **** Usage ****REM You need to pass in the path for the root of your Umbraco directoryREM E.g. umbPermissions.bat C:\inetpub\umbracoroot@echo umbPermissions.bat - Script to set Umbraco File and Directory Permissions@echo Published by Chris Houston - 29th May 2009@echo http://blog.vizioz.comSetACL.exe -on "%1\web.config" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\bin" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\config" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\css" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\data" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\masterpages" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\scripts" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\umbraco" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\umbraco_client" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\usercontrols" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"SetACL.exe -on "%1\xslt" -ot file -actn ace -ace "n:%computername%\NETWORK SERVICE;p:full"Feel free to comment if I missed anything!

  Read the article

• Vizioz is back on the web

  - by Vizioz Limited

  I founded Vizioz in 1996 as a website development business. Since then Vizioz has come in and out of focus, it is time to start building Vizioz into a website development consultancy. Over the following two months we will be launching our new website where we will be promoting our ASP.NET, C#, XHTML, CSS, XSLT, SQL, Umbraco Development, Wordpress Development and Graphic Design services, and of course our website will be powered by the open source content management system called Umbraco CMS which we have used for 10+ client sites in the last twelve months.I will be using this new blog to talk about client projects we are currently working on and any Umbraco development related bits of code that we feel would be good to release back to the Umbraco community.

  Read the article

• StarterSTS v1.5 Beta 1

  - by Your DisplayName here!

  I just uploaded a new drop of StarterSTS. This release has many changes and new features, e.g.: Built-in support for Windows Azure Caching New REST endpoint Federated Sign-Out Extended tracing (including real time tracing to a WCF service and logging of RST(R)s and tokens) I will drill deeper into the new features in the forthcoming blog posts. Please try it out and give me feedback.

  Read the article

• WIF, ADFS 2 and WCF&ndash;Part 6: Chaining multiple Token Services

  - by Your DisplayName here!

  See the previous posts first. So far we looked at the (simpler) scenario where a client acquires a token from an identity provider and uses that for authentication against a relying party WCF service. Another common scenario is, that the client first requests a token from an identity provider, and then uses this token to request a new token from a Resource STS or a partner’s federation gateway. This sounds complicated, but is actually very easy to achieve using WIF’s WS-Trust client support. The sequence is like this: Request a token from an identity provider. You use some “bootstrap” credential for that like Windows integrated, UserName or a client certificate. The realm used for this request is the identifier of the Resource STS/federation gateway. Use the resulting token to request a new token from the Resource STS/federation gateway. The realm for this request would be the ultimate service you want to talk to. Use this resulting token to authenticate against the ultimate service. Step 1 is very much the same as the code I have shown in the last post. In the following snippet, I use a client certificate to get a token from my STS: private static SecurityToken GetIdPToken() {     var factory = new WSTrustChannelFactory(         new CertificateWSTrustBinding(SecurityMode.TransportWithMessageCredential,         idpEndpoint);     factory.TrustVersion = TrustVersion.WSTrust13;       factory.Credentials.ClientCertificate.SetCertificate(         StoreLocation.CurrentUser,         StoreName.My,         X509FindType.FindBySubjectDistinguishedName,         "CN=Client");       var rst = new RequestSecurityToken     {         RequestType = RequestTypes.Issue,         AppliesTo = new EndpointAddress(rstsRealm),         KeyType = KeyTypes.Symmetric     };       var channel = factory.CreateChannel();     return channel.Issue(rst); } To use a token to request another token is slightly different. First the IssuedTokenWSTrustBinding is used and second the channel factory extension methods are used to send the identity provider token to the Resource STS: private static SecurityToken GetRSTSToken(SecurityToken idpToken) {     var binding = new IssuedTokenWSTrustBinding();     binding.SecurityMode = SecurityMode.TransportWithMessageCredential;       var factory = new WSTrustChannelFactory(         binding,         rstsEndpoint);     factory.TrustVersion = TrustVersion.WSTrust13;     factory.Credentials.SupportInteractive = false;       var rst = new RequestSecurityToken     {         RequestType = RequestTypes.Issue,         AppliesTo = new EndpointAddress(svcRealm),         KeyType = KeyTypes.Symmetric     };       factory.ConfigureChannelFactory();     var channel = factory.CreateChannelWithIssuedToken(idpToken);     return channel.Issue(rst); } For this particular case I chose an ADFS endpoint for issued token authentication (see part 1 for more background). Calling the service now works exactly like I described in my last post. You may now wonder if the same thing can be also achieved using configuration only – absolutely. But there are some gotchas. First of all the configuration files becomes quite complex. As we discussed in part 4, the bindings must be nested for WCF to unwind the token call-stack. But in this case svcutil cannot resolve the first hop since it cannot use metadata to inspect the identity provider. This binding must be supplied manually. The other issue is around the value for the realm/appliesTo when requesting a token for the R-STS. Using the manual approach you have full control over that parameter and you can simply use the R-STS issuer URI. Using the configuration approach, the exact address of the R-STS endpoint will be used. This means that you may have to register multiple R-STS endpoints in the identity provider. Another issue you will run into is, that ADFS does only accepts its configured issuer URI as a known realm by default. You’d have to manually add more audience URIs for the specific endpoints using the ADFS Powershell commandlets. I prefer the “manual” approach. That’s it. Hope this is useful information.

  Read the article

• WIF, ADFS 2 and WCF&ndash;Part 5: Service Client (more Flexibility with WSTrustChannelFactory)

  - by Your DisplayName here!

  See the previous posts first. WIF includes an API to manually request tokens from a token service. This gives you more control over the request and more flexibility since you can use your own token caching scheme instead of being bound to the channel object lifetime. The API is straightforward. You first request a token from the STS and then use that token to create a channel to the relying party service. I’d recommend using the WS-Trust bindings that ship with WIF to talk to ADFS 2 – they are pre-configured to match the binding configuration of the ADFS 2 endpoints. The following code requests a token for a WCF service from ADFS 2: private static SecurityToken GetToken() {     // Windows authentication over transport security     var factory = new WSTrustChannelFactory(         new WindowsWSTrustBinding(SecurityMode.Transport),         stsEndpoint);     factory.TrustVersion = TrustVersion.WSTrust13;       var rst = new RequestSecurityToken     {         RequestType = RequestTypes.Issue,         AppliesTo = new EndpointAddress(svcEndpoint),         KeyType = KeyTypes.Symmetric     };       var channel = factory.CreateChannel();     return channel.Issue(rst); } Afterwards, the returned token can be used to create a channel to the service. Again WIF has some helper methods here that make this very easy: private static void CallService(SecurityToken token) {     // create binding and turn off sessions     var binding = new WS2007FederationHttpBinding(         WSFederationHttpSecurityMode.TransportWithMessageCredential);     binding.Security.Message.EstablishSecurityContext = false;       // create factory and enable WIF plumbing     var factory = new ChannelFactory<IService>(binding, new EndpointAddress(svcEndpoint));     factory.ConfigureChannelFactory<IService>();       // turn off CardSpace - we already have the token     factory.Credentials.SupportInteractive = false;       var channel = factory.CreateChannelWithIssuedToken<IService>(token);       channel.GetClaims().ForEach(c =>         Console.WriteLine("{0}\n {1}\n  {2} ({3})\n",             c.ClaimType,             c.Value,             c.Issuer,             c.OriginalIssuer)); } Why is this approach more flexible? Well – some don’t like the configuration voodoo. That’s a valid reason for using the manual approach. You also get more control over the token request itself since you have full control over the RST message that gets send to the STS. One common parameter that you may want to set yourself is the appliesTo value. When you use the automatic token support in the WCF federation binding, the appliesTo is always the physical service address. This means in turn that this address will be used as the audience URI value in the SAML token. Well – this in turn means that when you have an application that consists of multiple services, you always have to configure all physical endpoint URLs in ADFS 2 and in the WIF configuration of the service(s). Having control over the appliesTo allows you to use more symbolic realm names, e.g. the base address or a completely logical name. Since the URL is never de-referenced you have some degree of freedom here. In the next post we will look at the necessary code to request multiple tokens in a call chain. This is a common scenario when you first have to acquire a token from an identity provider and have to send that on to a federation gateway or Resource STS. Stay tuned.

  Read the article

• WIF, ADFS 2 and WCF&ndash;Part 4: Service Client (using Service Metadata)

  - by Your DisplayName here!

  See parts 1, 2 and 3 first. In this part we will finally build a client for our federated service. There are basically two ways to accomplish this. You can use the WCF built-in tooling to generate client and configuration via the service metadata (aka ‘Add Service Reference’). This requires no WIF on the client side. Another approach would be to use WIF’s WSTrustChannelFactory to manually talk to the ADFS 2 WS-Trust endpoints. This option gives you more flexibility, but is slightly more code to write. You also need WIF on the client which implies that you need to run on a WIF supported operating system – this rules out e.g. Windows XP clients. We’ll start with the metadata way. You simply create a new client project (e.g. a console app) – call ‘Add Service Reference’ and point the dialog to your service endpoint. What will happen then is, that VS will contact your service and read its metadata. Inside there is also a link to the metadata endpoint of ADFS 2. This one will be contacted next to find out which WS-Trust endpoints are available. The end result will be a client side proxy and a configuration file. Let’s first write some code to call the service and then have a closer look at the config file. var proxy = new ServiceClient(); proxy.GetClaims().ForEach(c =>     Console.WriteLine("{0}\n {1}\n  {2} ({3})\n",         c.ClaimType,         c.Value,         c.Issuer,         c.OriginalIssuer)); That’s all. The magic is happening in the configuration file. When you in inspect app.config, you can see the following general configuration hierarchy: <client /> element with service endpoint information federation binding and configuration containing ADFS 2 endpoint 1 (with binding and configuration) ADFS 2 endpoint n (with binding and configuration) (where ADFS 2 endpoint 1…n are the endpoints I talked about in part 1) You will see a number of <issuer /> elements in the binding configuration where simply the first endpoint from the ADFS 2 metadata becomes the default endpoint and all other endpoints and their configuration are commented out. You now need to find the endpoint you want to use (based on trust version, credential type and security mode) and replace that with the default endpoint. That’s it. When you call the WCF proxy, it will inspect configuration, then first contact the selected ADFS 2 endpoint to request a token. This token will then be used to authenticate against the service. In the next post I will show you the more manual approach using the WIF APIs.

  Read the article

• WIF, ADFS 2 and WCF&ndash;Part 3: ADFS Setup

  - by Your DisplayName here!

  In part 1 of this series I briefly gave an overview of the ADFS / WS-Trust infrastructure. In part 2 we created a basic WCF service that uses ADFS for authentication. This part will walk you through the steps to register the service in ADFS 2. I could provide screenshots for all the wizard pages here – but since this is really easy – I just go through the necessary steps in textual form. Step 1 – Select Data Source Here you can decide if you want to import a federation metadata file that describes the service you want to register. In that case all necessary information is inside the metadata document and you are done. FedUtil (a tool that ships with WIF) can generate such metadata for the most simple cases. Another tool to create metadata can be found here. We choose ‘Manual’ here. Step 2 – Specify Display Name I guess that’s self explaining. Step 3 – Choose Profile Choose ‘ADFS 2 Profile’ here. Step 4 – Configure Certificate Remember that we specified a certificate (or rather a private key) to be used to decrypting incoming tokens in the previous post. Here you specify the corresponding public key that ADFS 2 should use for encrypting the token. Step 5 – Configure URL This page is used to configure WS-Federation and SAML 2.0p support. Since we are using WS-Trust you can leave both boxes unchecked. Step 6 – Configure Identifier Here you specify the identifier (aka the realm, aka the appliesTo) that will be used to request tokens for the service. This value will be used in the token request and is used by ADFS 2 to make a connection to the relying party configuration and claim rules. Step 7 – Configure Issuance Authorization Rules Here you can configure who is allowed to request token for the service. I won’t go into details here how these rules exactly work – that’s for a separate blog post. For now simply use the “Permit all users” option. OK – that’s it. The service is now registered at ADFS 2. In the next part we will finally look at the service client. Stay tuned…

  Read the article

• WIF, ADFS 2 and WCF&ndash;Part 2: The Service

  - by Your DisplayName here!

  OK – so let’s first start with a simple WCF service and connect that to ADFS 2 for authentication. The service itself simply echoes back the user’s claims – just so we can make sure it actually works and to see how the ADFS 2 issuance rules emit claims for the service: [ServiceContract(Namespace = "urn:leastprivilege:samples")] public interface IService {     [OperationContract]     List<ViewClaim> GetClaims(); } public class Service : IService {     public List<ViewClaim> GetClaims()     {         var id = Thread.CurrentPrincipal.Identity as IClaimsIdentity;         return (from c in id.Claims                 select new ViewClaim                 {                     ClaimType = c.ClaimType,                     Value = c.Value,                     Issuer = c.Issuer,                     OriginalIssuer = c.OriginalIssuer                 }).ToList();     } } The ViewClaim data contract is simply a DTO that holds the claim information. Next is the WCF configuration – let’s have a look step by step. First I mapped all my http based services to the federation binding. This is achieved by using .NET 4.0’s protocol mapping feature (this can be also done the 3.x way – but in that scenario all services will be federated): <protocolMapping>   <add scheme="http" binding="ws2007FederationHttpBinding" /> </protocolMapping> Next, I provide a standard configuration for the federation binding: <bindings>   <ws2007FederationHttpBinding>     <binding>       <security mode="TransportWithMessageCredential">         <message establishSecurityContext="false">           <issuerMetadata address="https://server/adfs/services/trust/mex" />         </message>       </security>     </binding>   </ws2007FederationHttpBinding> </bindings> This binding points to our ADFS 2 installation metadata endpoint. This is all that is needed for svcutil (aka “Add Service Reference”) to generate the required client configuration. I also chose mixed mode security (SSL + basic message credential) for best performance. This binding also disables session – you can control that via the establishSecurityContext setting on the binding. This has its pros and cons. Something for a separate blog post, I guess. Next, the behavior section adds support for metadata and WIF: <behaviors>   <serviceBehaviors>     <behavior>       <serviceMetadata httpsGetEnabled="true" />       <federatedServiceHostConfiguration />     </behavior>   </serviceBehaviors> </behaviors> The next step is to add the WIF specific configuration (in <microsoft.identityModel />). First we need to specify the key material that we will use to decrypt the incoming tokens. This is optional for web applications but for web services you need to protect the proof key – so this is mandatory (at least for symmetric proof keys, which is the default): <serviceCertificate>   <certificateReference storeLocation="LocalMachine"                         storeName="My"                         x509FindType="FindBySubjectDistinguishedName"                         findValue="CN=Service" /> </serviceCertificate> You also have to specify which incoming tokens you trust. This is accomplished by registering the thumbprint of the signing keys you want to accept. You get this information from the signing certificate configured in ADFS 2: <issuerNameRegistry type="...ConfigurationBasedIssuerNameRegistry">   <trustedIssuers>     <add thumbprint="d1 … db"           name="ADFS" />   </trustedIssuers> </issuerNameRegistry> The last step (promised) is to add the allowed audience URIs to the configuration – WCF clients use (by default – and we’ll come back to this) the endpoint address of the service: <audienceUris>   <add value="https://machine/soapadfs/service.svc" /> </audienceUris> OK – that’s it – now we have a basic WCF service that uses ADFS 2 for authentication. The next step will be to set-up ADFS to issue tokens for this service. Afterwards we can explore various options on how to use this service from a client. Stay tuned… (if you want to have a look at the full source code or peek at the upcoming parts – you can download the complete solution here)

  Read the article

• WIF, ADFS 2 and WCF&ndash;Part 1: Overview

  - by Your DisplayName here!

  A lot has been written already about passive federation and integration of WIF and ADFS 2 into web apps. The whole active/WS-Trust feature area is much less documented or covered in articles and blogs. Over the next few posts I will try to compile all relevant information about the above topics – but let’s start with an overview. ADFS 2 has a number of endpoints under the /services/trust base address that implement the WS-Trust protocol. They are grouped by the WS-Trust version they support (/13 and /2005), the client credential type (/windows*, /username*, /certificate*) and the security mode (*transport, *mixed and message). You can see the endpoints in the MMC console under the Service/Endpoints page. So in other words, you use one of these endpoints (which exactly depends on your configuration / system setup) to request tokens from ADFS 2. The bindings behind the endpoints are more or less standard WCF bindings, but with SecureConversation (establishSecurityContext) disabled. That means that whenever you need to programmatically talk to these endpoints – you can (easily) create client bindings that are compatible. Another option is to use the special bindings that come with WIF (in the Microsoft.IdentityModel.Protocols.WSTrust.Bindings namespace). They are already pre-configured to be compatible with the ADFS endpoints. The downside of these bindings is, that you can’t use them in configuration. That’s definitely a feature request of mine for the next version of WIF. The next important piece of information is the so called Federation Service Identifier. This is the value that you (at least by default) have to use as a realm/appliesTo whenever you are requesting a token for ADFS (e.g. in  IdP –> RSTS scenario). Or (even more) technically speaking, ADFS 2 checks for this value in the audience URI restriction in SAML tokens. You can get to this value by clicking the “Edit Federation Service Properties” in the MMC when the Service tree-node is selected. OK – I will come back to this basic information in the following posts. Basically I want to go through the following scenarios: ADFS in the IdP role ADFS in the R-STS role (with a chained claims provider) Using the WCF bindings for automatic token issuance Using WSTrustChannelFactory for manual token handling Stay tuned…

  Read the article

• StarterSTS v1.5 CTP

  - by Your DisplayName here!

  I just uploaded a new version of StarterSTS to Codeplex. There have been some dramatic changes since the last public version, so any feedback would be appreciated. This new version is now a .NET 4.0 web application project, and includes all the necessary plumbing and configuration to deploy StarterSTS to Azure. In fact it is just a configuration change to choose between the Azure and on-premise version. Download: http://startersts.codeplex.com/releases/view/52214 More info: Moving StarterSTS to the (Azure) Cloud

  Read the article

• Fiddler Inspector for Federation Messages

  - by Your DisplayName here!

  Fiddler is a very useful tool for troubleshooting all kinds of HTTP(s) communications. It also features various extensibility points to make it even more useful. Using the inspector extensibility mechanism, I quickly knocked up an inspector for typical federation messages (thanks for Eric Lawrence btw). Below is a screenshot for WS-Federation. I also added support for SAML 2.0p request/response messages: The inspector can be downloaded from the identitymodel Codeplex site. Simply copy the binary to the inspector folder in the Fiddler directory.

  Read the article

• Access Control Service v2

  - by Your DisplayName here!

  A Resource-STS (others call it RP-STS or federation gateway) is a necessity for non-trivial federated identity scenarios. ADFS v2 does an excellent job in fulfilling that role – but (as of now) you have to run ADFS on-premise. The Azure Access Control Service is a Resource-STS in the cloud (with all the usual scalability/availability) promises. Unfortunately a lot of (the more interesting) features in ACS v1 had to be cut due to constrained time/resources. The good news is that ACS v2 is now in CTP and brings back a lot of the missing features (like WS* support) and adds some really sweet new ones (out of the box federation with Google, Facebook, LiveID – and OpenId in general). You can read about the details here. On a related note – ACS v2 works out of the box with StarterSTS – simply choose the ADFS v2 option and point the management portal to the StarterSTS WS-Federation metadata endpoint. Have fun ;)

  Read the article

• Moving StarterSTS to the (Azure) Cloud

  - by Your DisplayName here!

  Quite some people asked me about an Azure version of StarterSTS. While I kinda knew what I had to do to make the move, I couldn’t find the time. Until recently. This blog post briefly documents the necessary changes and design decisions for the next version of StarterSTS which will work both on-premise and on Azure. Provider Fortunately StarterSTS is already based on the idea of “providers”. Authentication, roles and claims generation is based on the standard ASP.NET provider infrastructure. This makes the migration to different data stores less painful. In my case I simply moved the ASP.NET provider database to SQL Azure and still use the standard SQL Server based membership, roles and profile provider. In addition StarterSTS has its own providers to abstract resource access for certificates, relying party registration, client certificate registration and delegation. So I only had to provide new implementations. Signing and SSL keys now go in the Azure certificate store and user mappings (client certificates and delegation settings) have been moved to Azure table storage. The one thing I didn’t anticipate when I originally wrote StarterSTS was the need to also encapsulate configuration. Currently configuration is “locked” to the standard .NET configuration system. The new version will have a pluggable SettingsProvider with versions for .NET configuration as well as Azure service configuration. If you want to externalize these settings into e.g. a database, it is now just a matter of supplying a corresponding provider. Moving between the on-premise and Azure version will be just a matter of using different providers. URL Handling Another thing that’s substantially different on Azure (and load balanced scenarios in general) is the handling of URLs. In farm scenarios, the standard APIs like ASP.NET’s Request.Url return the current (internal) machine name, but you typically need the address of the external facing load balancer. There’s a hotfix for WCF 3.5 (included in v4) that fixes this for WCF metadata. This was accomplished by using the HTTP Host header to generate URLs instead of the local machine name. I now use the same approach for generating WS-Federation metadata as well as information card files. New Features I introduced a cache provider. Since we now have slightly more expensive lookups (e.g. relying party data from table storage), it makes sense to cache certain data in the front end. The default implementation uses the ASP.NET web cache and can be easily extended to use products like memcached or AppFabric Caching. Starting with the relying party provider, I now also provide a read/write interface. This allows building management interfaces on top of this provider. I also include a (very) simple web page that allows working with the relying party provider data. I guess I will use the same approach for other providers in the future as well. I am also doing some work on the tracing and health monitoring area. Especially important for the Azure version. Stay tuned.

  Read the article

• WIF, ASP.NET 4.0 and Request Validation

  - by Your DisplayName here!

  Since the response of a WS-Federation sign-in request contains XML, the ASP.NET built-in request validation will trigger an exception. To solve this, request validation needs to be turned off for pages receiving such a response message. Starting with ASP.NET 4.0 you can plug in your own request validation logic. This allows letting WS-Federation messages through, while applying all standard request validation to all other requests. The WIF SDK (v4) contains a sample validator that does exactly that: public class WSFedRequestValidator : RequestValidator {     protected override bool IsValidRequestString(       HttpContext context,       string value,       RequestValidationSource requestValidationSource,       string collectionKey,       out int validationFailureIndex)     {         validationFailureIndex = 0;         if ( requestValidationSource == RequestValidationSource.Form &&              collectionKey.Equals(                WSFederationConstants.Parameters.Result,                StringComparison.Ordinal ) )         {             SignInResponseMessage message =               WSFederationMessage.CreateFromFormPost(context.Request)                as SignInResponseMessage;             if (message != null)             {                 return true;             }         }         return base.IsValidRequestString(           context,           value,           requestValidationSource,           collectionKey,           out validationFailureIndex );     } } Register this validator via web.config: <httpRuntime requestValidationType="WSFedRequestValidator" />

  Read the article

• Modifying the SL/WIF Integration Bits to support Issued Token Credentials

  - by Your DisplayName here!

  The SL/WIF integration code that ships with the Identity Training Kit only supports Windows and UserName credentials to request tokens from an STS. This is fine for simple single STS scenarios (like a single IdP). But the more common pattern for claims/token based systems is to split the STS roles into an IdP and a Resource STS (or whatever you wanna call it). In this case, the 2nd leg requires to present the issued token from the 1st leg – this is not directly supported by the bits. But they can be easily modified to accomplish this. The Credential Fist we need a class that represents an issued token credential. Here we store the RSTR that got returned from the client to IdP request: public class IssuedTokenCredentials : IRequestCredentials {     public string IssuedToken { get; set; }     public RequestSecurityTokenResponse RSTR { get; set; }     public IssuedTokenCredentials(RequestSecurityTokenResponse rstr)     {         RSTR = rstr;         IssuedToken = rstr.RequestedSecurityToken.RawToken;     } } The Binding Next we need a binding to be used with issued token credential requests. This assumes you have an STS endpoint for mixed mode security with SecureConversation turned off. public class WSTrustBindingIssuedTokenMixed : WSTrustBinding {     public WSTrustBindingIssuedTokenMixed()     {         this.Elements.Add( new HttpsTransportBindingElement() );     } } WSTrustClient The last step is to make some modifications to WSTrustClient to make it issued token aware. In the constructor you have to check for the credential type, and if it is an issued token, store it away. private RequestSecurityTokenResponse _rstr; public WSTrustClient( Binding binding, EndpointAddress remoteAddress, IRequestCredentials credentials )     : base( binding, remoteAddress ) {     if ( null == credentials )     {         throw new ArgumentNullException( "credentials" );     }     if (credentials is UsernameCredentials)     {         UsernameCredentials usernname = credentials as UsernameCredentials;         base.ChannelFactory.Credentials.UserName.UserName = usernname.Username;         base.ChannelFactory.Credentials.UserName.Password = usernname.Password;     }     else if (credentials is IssuedTokenCredentials)     {         var issuedToken = credentials as IssuedTokenCredentials;         _rstr = issuedToken.RSTR;     }     else if (credentials is WindowsCredentials)     { }     else     {         throw new ArgumentOutOfRangeException("credentials", "type was not expected");     } } Next – when WSTrustClient constructs the RST message to the STS, the issued token header must be embedded when needed: private Message BuildRequestAsMessage( RequestSecurityToken request ) {     var message = Message.CreateMessage( base.Endpoint.Binding.MessageVersion ?? MessageVersion.Default,       IssueAction,       (BodyWriter) new WSTrustRequestBodyWriter( request ) );     if (_rstr != null)     {         message.Headers.Add(new IssuedTokenHeader(_rstr));     }     return message; } HTH

  Read the article

< Previous Page | 15 16 17 18 19 20 21 22  | Next Page >