Daily Archives

Articles indexed Monday June 20 2011

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

  • Access Control Service: Home Realm Discovery (HRD) Gotcha

    - by Your DisplayName here!
    I really like ACS2. One feature that is very useful is home realm discovery. ACS provides a Nascar style list as well as discovery based on email addresses. You can take control of the home realm selection process yourself by downloading the JSON feed or by manually setting the home realm parameter. Plenty of options – the only option missing is turning it off… In other words, when you setup your ACS namespace and realm and register identity provider, there is no way to keep the list of identity providers secret. An interested “user” can always retrieve all registered identity provider (using the browser or download the JSON feed). This may not be an issue with web identity providers, but when you use ACS to federate with customers or business partners, you maybe don’t want to disclose that list to the public (or to other customers). This is an adoption blocker for certain situations. I hope this feature will be added soon. In addition I would also like to see a feature I call “home realm aliases”. Some random string that I can use as a whr parameter instead of using the real issuer URI.

    Read the article

  • Access Control Service: Walkthrough Videos of Web Application, SOAP, REST and Silverlight Integration

    - by Your DisplayName here!
    Over the weekend I worked a little more on my ACS2 sample. Instead of writing it all down, I decided to quickly record four short videos that cover the relevant features and code. Have fun ;) Part 1 – Overview This video does a quick walkthrough of the solution and shows the web application part. This includes driving the sign in UI via JavaScript (thanks Matias) as well as the registration logic I wrote about here. watch Part 2 – SOAP Service and Client The sample app also exposes a WCF SOAP service. This video shows how to wire up the service to ACS and hows how to create a client that first requests a token from an IdP and then sends this token to ACS. watch Part 3 – REST Service and Client This part shows how to set up a WCF REST service that consumes SWT tokens from ACS. Unfortunately there is currently no standard WIF plumbing for REST. For the service integration I had to combine a lot of code from different sources (kzu, zulfiq) as well as the WIF SDK and OAuth CTPs together. But it is working. watch Part 4 – Silverlight and Web Identity Integration This part took by far the most time to write. The Silverlight Client shows ho to sign in to the application using a registered identity provider (including web identities) and using the resulting SWT token to call our REST service. This is designed to be a desktop (OOB) client application (thanks to Jörg for the UI magic). watch code download

    Read the article

  • Requesting Delegation (ActAs) Tokens using WSTrustChannel (as opposed to Configuration Madness)

    - by Your DisplayName here!
    Delegation using the ActAs approach has some interesting security features A security token service can make authorization and validation checks before issuing the ActAs token. Combined with proof keys you get non-repudiation features. The ultimate receiver sees the original caller as direct caller and can optionally traverse the delegation chain. Encryption and audience restriction can be tied down Most samples out there (including the SDK sample) use the CreateChannelActingAs extension method from WIF to request ActAs tokens. This method builds on top of the WCF binding configuration which may not always be suitable for your situation. You can also use the WSTrustChannel to request ActAs tokens. This allows direct and programmatic control over bindings and configuration and is my preferred approach. The below method requests an ActAs token based on a bootstrap token. The returned token can then directly be used with the CreateChannelWithIssued token extension method. private SecurityToken GetActAsToken(SecurityToken bootstrapToken) {     var factory = new WSTrustChannelFactory(         new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential),         new EndpointAddress(_stsAddress));     factory.TrustVersion = TrustVersion.WSTrust13;     factory.Credentials.UserName.UserName = "middletier";     factory.Credentials.UserName.Password = "abc!123";     var rst = new RequestSecurityToken     {         AppliesTo = new EndpointAddress(_serviceAddress),         RequestType = RequestTypes.Issue,         KeyType = KeyTypes.Symmetric,         ActAs = new SecurityTokenElement(bootstrapToken)     };     var channel = factory.CreateChannel();     var delegationToken = channel.Issue(rst);     return delegationToken; }   HTH

    Read the article

  • Access Control Service v2: Registering Web Identities in your Applications [code]

    - by Your DisplayName here!
    You can download the full solution here. The relevant parts in the sample are: Configuration I use the standard WIF configuration with passive redirect. This kicks automatically in, whenever authorization fails in the application (e.g. when the user tries to get to an area the requires authentication or needs registration). Checking and transforming incoming claims In the claims authentication manager we have to deal with two situations. Users that are authenticated but not registered, and registered (and authenticated) users. Registered users will have claims that come from the application domain, the claims of unregistered users come directly from ACS and get passed through. In both case a claim for the unique user identifier will be generated. The high level logic is as follows: public override IClaimsPrincipal Authenticate( string resourceName, IClaimsPrincipal incomingPrincipal) {     // do nothing if anonymous request     if (!incomingPrincipal.Identity.IsAuthenticated)     {         return base.Authenticate(resourceName, incomingPrincipal);     } string uniqueId = GetUniqueId(incomingPrincipal);     // check if user is registered     RegisterModel data;     if (Repository.TryGetRegisteredUser(uniqueId, out data))     {         return CreateRegisteredUserPrincipal(uniqueId, data);     }     // authenticated by ACS, but not registered     // create unique id claim     incomingPrincipal.Identities[0].Claims.Add( new Claim(Constants.ClaimTypes.Id, uniqueId));     return incomingPrincipal; } User Registration The registration page is handled by a controller with the [Authorize] attribute. That means you need to authenticate before you can register (crazy eh? ;). The controller then fetches some claims from the identity provider (if available) to pre-fill form fields. After successful registration, the user is stored in the local data store and a new session token gets issued. This effectively replaces the ACS claims with application defined claims without requiring the user to re-signin. Authorization All pages that should be only reachable by registered users check for a special application defined claim that only registered users have. You can nicely wrap that in a custom attribute in MVC: [RegisteredUsersOnly] public ActionResult Registered() {     return View(); } HTH

    Read the article

  • Access Control Service v2: Registering Web Identities in your Applications [concepts]

    - by Your DisplayName here!
    ACS v2 support two fundamental types of client identities– I like to call them “enterprise identities” (WS-*) and “web identities” (Google, LiveID, OpenId in general…). I also see two different “mind sets” when it comes to application design using the above identity types: Enterprise identities – often the fact that a client can present a token from a trusted identity provider means he is a legitimate user of the application. Trust relationships and authorization details have been negotiated out of band (often on paper). Web identities – the fact that a user can authenticate with Google et al does not necessarily mean he is a legitimate (or registered) user of an application. Typically additional steps are necessary (like filling out a form, email confirmation etc). Sometimes also a mixture of both approaches exist, for the sake of this post, I will focus on the web identity case. I got a number of questions how to implement the web identity scenario and after some conversations it turns out it is the old authentication vs. authorization problem that gets in the way. Many people use the IsAuthenticated property on IIdentity to make security decisions in their applications (or deny user=”?” in ASP.NET terms). That’s a very natural thing to do, because authentication was done inside the application and we knew exactly when the IsAuthenticated condition is true. Been there, done that. Guilty ;) The fundamental difference between these “old style” apps and federation is, that authentication is not done by the application anymore. It is done by a third party service, and in the case of web identity providers, in services that are not under our control (nor do we have a formal business relationship with these providers). Now the issue is, when you switch to ACS, and someone with a Google account authenticates, indeed IsAuthenticated is true – because that’s what he is! This does not mean, that he is also authorized to use the application. It just proves he was able to authenticate with Google. Now this obviously leads to confusion. How can we solve that? Easy answer: We have to deal with authentication and authorization separately. Job done ;) For many application types I see this general approach: Application uses ACS for authentication (maybe both enterprise and web identities, we focus on web identities but you could easily have a dual approach here) Application offers to authenticate (or sign in) via web identity accounts like LiveID, Google, Facebook etc. Application also maintains a database of its “own” users. Typically you want to store additional information about the user In such an application type it is important to have a unique identifier for your users (think the primary key of your user database). What would that be? Most web identity provider (and all the standard ACS v2 supported ones) emit a NameIdentifier claim. This is a stable ID for the client (scoped to the relying party – more on that later). Furthermore ACS emits a claims identifying the identity provider (like the original issuer concept in WIF). When you combine these two values together, you can be sure to have a unique identifier for the user, e.g.: Facebook-134952459903700\799880347 You can now check on incoming calls, if the user is already registered and if yes, swap the ACS claims with claims coming from your user database. One claims would maybe be a role like “Registered User” which can then be easily used to do authorization checks in the application. The WIF claims authentication manager is a perfect place to do the claims transformation. If the user is not registered, show a register form. Maybe you can use some claims from the identity provider to pre-fill form fields. (see here where I show how to use the Facebook API to fetch additional user properties). After successful registration (which may include other mechanisms like a confirmation email), flip the bit in your database to make the web identity a registered user. This is all very theoretical. In the next post I will show some code and provide a download link for the complete sample. More on NameIdentifier Identity providers “guarantee” that the name identifier for a given user in your application will always be the same. But different applications (in the case of ACS – different ACS namespaces) will see different name identifiers. This is by design to protect the privacy of users because identical name identifiers could be used to create “profiles” of some sort for that user. In technical terms they create the name identifier approximately like this: name identifier = Hash((Provider Internal User ID) + (Relying Party Address)) Why is this important to know? Well – when you change the name of your ACS namespace, the name identifiers will change as well and you will will lose your “connection” to your existing users. Oh an btw – never use any other claims (like email address or name) to form a unique ID – these can often be changed by users.

    Read the article

  • Thinktecture.IdentityServer Beta 1

    - by Your DisplayName here!
    I just upload beta 1 to codeplex. Please test this version and give me feedback. Some quick notes on setup Watch the intro screencast on the codeplex site. Use the setup tool to set the signing and SSL certificate. You can now also set the ACLs on the private key for your worker pool account. IIS is required . SSL for the IIS site the STS runs in is required. Users of the STS must be in the 'IdentityServerUsers' role. Admins of the STS must be in the 'IdentityServerAdministrators' roles. What’s new? Mainly smaller bits and pieces and some refactoring. The biggest under the cover change is a new authorization model for the STS itself. If, e.g. you don’t like the new roles I introduced, you can easily change the behavior in the claims authorization manager in the STS web site project. What’s missing? The big one is Azure support. Not that I ran into unforeseeable problems here, I just wanted to wait until the on-premise version is more stabilized. Now with B1 I can start adding Azure support back.

    Read the article

  • Improving WIF&rsquo;s Claims-based Authorization - Part 3 (Usage)

    - by Your DisplayName here!
    In the previous posts I showed off some of the additions I made to WIF’s authorization infrastructure. I now want to show some samples how I actually use these extensions. The following code snippets are from Thinktecture.IdentityServer on Codeplex. The following shows the MVC attribute on the WS-Federation controller: [ClaimsAuthorize(Constants.Actions.Issue, Constants.Resources.WSFederation)] public class WSFederationController : Controller or… [ClaimsAuthorize(Constants.Actions.Administration, Constants.Resources.RelyingParty)] public class RelyingPartiesAdminController : Controller In other places I used the imperative approach (e.g. the WRAP endpoint): if (!ClaimsAuthorize.CheckAccess(principal, Constants.Actions.Issue, Constants.Resources.WRAP)) {     Tracing.Error("User not authorized");     return new UnauthorizedResult("WRAP", true); } For the WCF WS-Trust endpoints I decided to use the per-request approach since the SOAP actions are well defined here. The corresponding authorization manager roughly looks like this: public class AuthorizationManager : ClaimsAuthorizationManager {     public override bool CheckAccess(AuthorizationContext context)     {         var action = context.Action.First();         var id = context.Principal.Identities.First();         // if application authorization request         if (action.ClaimType.Equals(ClaimsAuthorize.ActionType))         {             return AuthorizeCore(action, context.Resource, context.Principal.Identity as IClaimsIdentity);         }         // if ws-trust issue request         if (action.Value.Equals(WSTrust13Constants.Actions.Issue))         {             return AuthorizeTokenIssuance(new Collection<Claim> { new Claim(ClaimsAuthorize.ResourceType, Constants.Resources.WSTrust) }, id);         }         return base.CheckAccess(context);     } } You see that it is really easy now to distinguish between per-request and application authorization which makes the overall design much easier. HTH

    Read the article

  • Improving WIF&rsquo;s Claims-based Authorization - Part 2

    - by Your DisplayName here!
    In the last post I showed you how to take control over the invocation of ClaimsAuthorizationManager. Then you have complete freedom over the claim types, the amount of claims and the values. In addition I added two attributes that invoke the authorization manager using an “application claim type”. This way it is very easy to distinguish between authorization calls that originate from WIF’s per-request authorization and the ones from “within” you application. The attribute comes in two flavours: a CAS attribute (invoked by the CLR) and an ASP.NET MVC attribute (for MVC controllers, invoke by the MVC plumbing). Both also feature static methods to easily call them using the application claim types. The CAS attribute is part of Thinktecture.IdentityModel on Codeplex (or via NuGet: Install-Package Thinktecture.IdentityModel). If you really want to see that code ;) There is also a sample included in the Codeplex donwload. The MVC attribute is currently used in Thinktecture.IdentityServer – and I don’t currently plan to make it part of the library project since I don’t want to add a dependency on MVC for now. You can find the code below – and I will write about its usage in a follow-up post. public class ClaimsAuthorize : AuthorizeAttribute {     private string _resource;     private string _action;     private string[] _additionalResources;     /// <summary>     /// Default action claim type.     /// </summary>     public const string ActionType = "http://application/claims/authorization/action";     /// <summary>     /// Default resource claim type     /// </summary>     public const string ResourceType = "http://application/claims/authorization/resource";     /// <summary>     /// Additional resource claim type     /// </summary>     public const string AdditionalResourceType = "http://application/claims/authorization/additionalresource"          public ClaimsAuthorize(string action, string resource, params string[] additionalResources)     {         _action = action;         _resource = resource;         _additionalResources = additionalResources;     }     public static bool CheckAccess(       string action, string resource, params string[] additionalResources)     {         return CheckAccess(             Thread.CurrentPrincipal as IClaimsPrincipal,             action,             resource,             additionalResources);     }     public static bool CheckAccess(       IClaimsPrincipal principal, string action, string resource, params string[] additionalResources)     {         var context = CreateAuthorizationContext(             principal,             action,             resource,             additionalResources);         return ClaimsAuthorization.CheckAccess(context);     }     protected override bool AuthorizeCore(HttpContextBase httpContext)     {         return CheckAccess(_action, _resource, _additionalResources);     }     private static WIF.AuthorizationContext CreateAuthorizationContext(       IClaimsPrincipal principal, string action, string resource, params string[] additionalResources)     {         var actionClaims = new Collection<Claim>         {             new Claim(ActionType, action)         };         var resourceClaims = new Collection<Claim>         {             new Claim(ResourceType, resource)         };         if (additionalResources != null && additionalResources.Length > 0)         {             additionalResources.ToList().ForEach(ar => resourceClaims.Add(               new Claim(AdditionalResourceType, ar)));         }         return new WIF.AuthorizationContext(             principal,             resourceClaims,             actionClaims);     } }

    Read the article

  • Improving WIF&rsquo;s Claims-based Authorization - Part 1

    - by Your DisplayName here!
    As mentioned in my last post, I made several additions to WIF’s built-in authorization infrastructure to make it more flexible and easy to use. The foundation for all this work is that you have to be able to directly call the registered ClaimsAuthorizationManager. The following snippet is the universal way to get to the WIF configuration that is currently in effect: public static ServiceConfiguration ServiceConfiguration {     get     {         if (OperationContext.Current == null)         {             // no WCF             return FederatedAuthentication.ServiceConfiguration;         }         // search message property         if (OperationContext.Current.IncomingMessageProperties. ContainsKey("ServiceConfiguration"))         {             var configuration = OperationContext.Current. IncomingMessageProperties["ServiceConfiguration"] as ServiceConfiguration;             if (configuration != null)             {                 return configuration;             }         }         // return configuration from configuration file         return new ServiceConfiguration();     } }   From here you can grab ServiceConfiguration.ClaimsAuthoriationManager which give you direct access to the CheckAccess method (and thus control over claim types and values). I then created the following wrapper methods: public static bool CheckAccess(string resource, string action) {     return CheckAccess(resource, action, Thread.CurrentPrincipal as IClaimsPrincipal); } public static bool CheckAccess(string resource, string action, IClaimsPrincipal principal) {     var context = new AuthorizationContext(principal, resource, action);     return AuthorizationManager.CheckAccess(context); } public static bool CheckAccess(Collection<Claim> actions, Collection<Claim> resources) {     return CheckAccess(new AuthorizationContext(         Thread.CurrentPrincipal.AsClaimsPrincipal(), resources, actions)); } public static bool CheckAccess(AuthorizationContext context) {     return AuthorizationManager.CheckAccess(context); } I also created the same set of methods but called DemandAccess. They internally use CheckAccess and will throw a SecurityException when false is returned. All the code is part of Thinktecture.IdentityModel on Codeplex – or via NuGet (Install-Package Thinktecture.IdentityModel).

    Read the article

  • What I don&rsquo;t like about WIF&rsquo;s Claims-based Authorization

    - by Your DisplayName here!
    In my last post I wrote about what I like about WIF’s proposed approach to authorization – I also said that I definitely would build upon that infrastructure for my own systems. But implementing such a system is a little harder as it could be. Here’s why (and that’s purely my perspective): First of all WIF’s authorization comes in two “modes” Per-request authorization. When an ASP.NET/WCF request comes in, the registered authorization manager gets called. For SOAP the SOAP action gets passed in. For HTTP requests (ASP.NET, WCF REST) the URL and verb. Imperative authorization This happens when you explicitly call the claims authorization API from within your code. There you have full control over the values for action and resource. In ASP.NET per-request authorization is optional (depends on if you have added the ClaimsAuthorizationHttpModule). In WCF you always get the per-request checks as soon as you register the authorization manager in configuration. I personally prefer the imperative authorization because first of all I don’t believe in URL based authorization. Especially in the times of MVC and routing tables, URLs can be easily changed – but then you also have to adjust your authorization logic every time. Also – you typically need more knowledge than a simple “if user x is allowed to invoke operation x”. One problem I have is, both the per-request calls as well as the standard WIF imperative authorization APIs wrap actions and resources in the same claim type. This makes it hard to distinguish between the two authorization modes in your authorization manager. But you typically need that feature to structure your authorization policy evaluation in a clean way. The second problem (which is somehow related to the first one) is the standard API for interacting with the claims authorization manager. The API comes as an attribute (ClaimsPrincipalPermissionAttribute) as well as a class to use programmatically (ClaimsPrincipalPermission). Both only allow to pass in simple strings (which results in the wrapping with standard claim types mentioned earlier). Both throw a SecurityException when the check fails. The attribute is a code access permission attribute (like PrincipalPermission). That means it will always be invoked regardless how you call the code. This may be exactly what you want, or not. In a unit testing situation (like an MVC controller) you typically want to test the logic in the function – not the security check. The good news is, the WIF API is flexible enough that you can build your own infrastructure around their core. For my own projects I implemented the following extensions: A way to invoke the registered claims authorization manager with more overloads, e.g. with different claim types or a complete AuthorizationContext. A new CAS attribute (with the same calling semantics as the built-in one) with custom claim types. A MVC authorization attribute with custom claim types. A way to use branching – as opposed to catching a SecurityException. I will post the code for these various extensions here – so stay tuned.

    Read the article

  • What I like about WIF&rsquo;s Claims-based Authorization

    - by Your DisplayName here!
    In “traditional” .NET with its IPrincipal interface and IsInRole method, developers were encouraged to write code like this: public void AddCustomer(Customer customer) {     if (Thread.CurrentPrincipal.IsInRole("Sales"))     {         // add customer     } } In code reviews I’ve seen tons of code like this. What I don’t like about this is, that two concerns in your application get tightly coupled: business and security logic. But what happens when the security requirements change – and they will (e.g. members of the sales role and some other people from different roles need to create customers)? Well – since your security logic is sprinkled across your project you need to change the security checks in all relevant places (and make sure you don’t forget one) and you need to re-test, re-stage and re-deploy the complete app. This is clearly not what we want. WIF’s claims-based authorization encourages developers to separate business code and authorization policy evaluation. This is a good thing. So the same security check with WIF’s out-of-the box APIs would look like this: public void AddCustomer(Customer customer) {     try     {         ClaimsPrincipalPermission.CheckAccess("Customer", "Add");           // add customer     }     catch (SecurityException ex)     {         // access denied     } } You notice the fundamental difference? The security check only describes what the code is doing (represented by a resource/action pair) – and does not state who is allowed to invoke the code. As I mentioned earlier – the who is most probably changing over time – the what most probably not. The call to ClaimsPrincipalPermission hands off to another class called the ClaimsAuthorizationManager. This class handles the evaluation of your security policy and is ideally in a separate assembly to allow updating the security logic independently from the application logic (and vice versa). The claims authorization manager features a method called CheckAccess that retrieves three values (wrapped inside an AuthorizationContext instance) – action (“add”), resource (“customer”) and the principal (including its claims) in question. CheckAccess then evaluates those three values and returns true/false. I really like the separation of concerns part here. Unfortunately there is not much support from Microsoft beyond that point. And without further tooling and abstractions the CheckAccess method quickly becomes *very* complex. But still I think that is the way to go. In the next post I will tell you what I don’t like about it (and how to fix it).

    Read the article

  • Access Control Service V2 and Facebook Integration

    - by Your DisplayName here!
    I haven’t been blogging about ACS2 in the past because it was not released and I was kinda busy with other stuff. Needless to say I spent quite some time with ACS2 already (both in customer situations as well as in the classroom and at conferences). ACS2 rocks! It’s IMHO the most interesting and useful (and most unique) part of the whole Azure offering! For my talk at VSLive yesterday, I played a little with the Facebook integration. See Steve’s post on the general setup. One claim that you get back from Facebook is an access token. This token can be used to directly talk to Facebook and query additional properties about the user. Which properties you have access to depends on which authorization your Facebook app requests. You can specify this in the identity provider registration page for Facebook in ACS2. In my example I added access to the home town property of the user. Once you have the access token from ACS you can use e.g. the Facebook SDK from Codeplex (also available via NuGet) to talk to the Facebook API. In my sample I used the WIF ClaimsAuthenticationManager to add the additional home town claim. This is not necessarily how you would do it in a “real” app. Depends ;) The code looks like this (sample code!): public class ClaimsTransformer : ClaimsAuthenticationManager {     public override IClaimsPrincipal Authenticate( string resourceName, IClaimsPrincipal incomingPrincipal)     {         if (!incomingPrincipal.Identity.IsAuthenticated)         {             return base.Authenticate(resourceName, incomingPrincipal);         }         string accessToken;         if (incomingPrincipal.TryGetClaimValue( "http://www.facebook.com/claims/AccessToken", out accessToken))         {             try             {                 var home = GetFacebookHometown(accessToken);                 if (!string.IsNullOrWhiteSpace(home))                 {                     incomingPrincipal.Identities[0].Claims.Add( new Claim("http://www.facebook.com/claims/HomeTown", home));                 }             }             catch { }         }         return incomingPrincipal;     }      private string GetFacebookHometown(string token)     {         var client = new FacebookClient(token);         dynamic parameters = new ExpandoObject();         parameters.fields = "hometown";         dynamic result = client.Get("me", parameters);         return result.hometown.name;     } }  

    Read the article

  • TechDays 2011 Sweden Videos

    - by Your DisplayName here!
    All the videos from the excellent Örebro event are now online. Dominick Baier: A Technical Introduction to the Windows Identity Foundation (watch) Dominick Baier & Christian Weyer: Securing REST-Services and Web APIs on the Windows Azure Platform (watch) Christian Weyer: Real World Azure - Elasticity from on-premise to the cloud and back (watch) Our interview with Robert (watch)

    Read the article

  • Using Robocopy to Backup to a NAS

    - by Your DisplayName here!
    When using Robocopy to backup data to a NAS, I always had the problem that most files were considered “old” on the NAS device (even if they weren’t) – that kind of defeats the purpose of the /MIR switch. Today I finally decided to search for a solution – and it was remarkably easy. Most NAS devices use Samba or something similar to provide “NTFS shares” – but most of them only implement FAT-style file times with a 2-second-granularity. You can force robocopy to use FAT file time as well using the /FFT switch. Now my backup script works again as expected. See also here.

    Read the article

  • Windows Security Videos auf Channel 9

    - by Your DisplayName here!
    Ich habe vor ein paar Wochen mit Lori drei Videos zum Thema Windows Security für Entwickler aufgenommen – die sind nun Online. Der erste Teil beschäftigt sich mit den absoluten Grundlagen der Windows Sicherheit. Was ist ein Konto? Was ist eine SID? Was ist ein Windows Token? Weiterhin wird gezeigt, wie sich diese grundlegenden Windows Einrichtungen über Managed Code anprogrammieren lassen. Der Vortrag endet mit einem kleinen Einblick in die Vorgehensweise von UAC, und wie dieses programmatisch verwendet werden kann. http://channel9.msdn.com/Blogs/Lori/Windows-Security-fr-Developers-Teil-1 Teil zwei beschäfitgt sich mit Zugriffs-Kontrolllisten, und wie diese mit .NET Code gelesen und geschrieben werden können. Weiterhin werden die beiden verwandten Konzepte Logon Session und Impersonierung besprochen. Beide Einrichtungen erzeugen einen neuen Token, sind aber grundlegend verschieden in ihren Einsatzgebieten. http://channel9.msdn.com/Blogs/Lori/Windows-Security-fr-Developers-Teil-2 Teil drei stellt das Kerberos Netzwerk-Authentifizierungsprotokoll vor. Da dieses Protokoll standardmäßig in Active Directory verwendet wird, sollten man es in den Grundzügen kennen. Natürlich kann auch Kerberos aus Managed Code verwendet werden – die abschließende Demo zeigt wie dies funktioniert. http://channel9.msdn.com/Blogs/Lori/Windows-Security-fr-Developers-Teil-3 …und noch ein kleines Interview http://channel9.msdn.com/Blogs/Lori/Interview-mit-Dominick-Baier Viel Spaß ;)

    Read the article

  • Value my C++ knowledge

    - by PirateOwh
    I have only followed antiRTFM tutorials and read 2 books So, I'll list the things I know better : basic input output and all the variables : integers ( signed unsigned ), float, double, char arrays if, for, while, switch functions, and passing variables to functions and return type thing classes and the concept of oop with separating declaration and definition in the header and in the source pointers so this and some more i think is all i know of C++.. But, i need some exercises to test my knowledge because i want to move on to the library SDL, so I don't know if i should feel ready or not to move on to something totally different.. I feel I should know the basics for good at least. So the question is : How can i value my c++ knowledge? Is there any online tests? Is there any GDD ( Game Design Document ) for free to use and see if i can manage to do it so "i'd pass" ? ( I'm saying GDD since ill move on to SDL and try to make my own game ) When should I move to SDL? What are ALL the things I should "master" ( master is a big word to say.. but so you understand what i mean ) before moving on ? Please I'm really in need of expert advice. I think my question is detailed so i hope you understand what i mean and can give me a good reply. Thanks for the help!

    Read the article

  • Is aspect oriented programming a misnomer?

    - by glenviewjeff
    From everything I have learned about "Aspect Oriented Programming" or "Aspect Oriented Software Development," labeling it as a programming paradigm or methodology appears to be inaccurate. From what I can tell it is not a fundamental technique for programming. To nail down what is meant by "paradigm" and "methodology," please refer to the following definitions from the American Heritage Dictionary. Compare how well or poorly "Object-Oriented Programming" applies to each vs. how well AOP fits. Paradigm: A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an intellectual discipline. Methodology: A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods. "Evidence-based medicine" satisfies the definition of paradigm, but "hysterectomy-based medicine" would be a misnomer because the problem space is too narrow. I am getting the impression that AOP may be misnamed because based on the "oriented-programming" suffix, AOP is alleging to be both a paradigm and a methodology in the same way "Object-Oriented Programming" is. Both of these terms (paradigm and methodology) indicate a fundamental technique, where what I understand about aspects is a technology for solving a narrow problem scope, maybe comparable in magnitude to the static variable feature of Java. If it's true that aspects solve a narrow set of problems, and AOP isn't a misnomer, then why shouldn't all programming techniques be given the "oriented-programming" suffix, such as "inheritance-oriented programming," "dependency-oriented programming," or "scope-oriented programming?"

    Read the article

  • How do I justify upgrading to Windows Server 2008?

    - by thebunk
    We're just about to start a new greenfield project - it's a highly functional web application using ASP.NET MVC3, SQL Server etc. We're also going to be using Windows Workflow Foundation for the first time. Our client only wants to use his existing Windows Server 2003 web servers. My main issue (other than it is 8 years old) is that we don't much experierence of WWF development, but understand that using AppFabric (Server 2008 only) will improve WWF development. It's a significant cost to the client, as we need fail-over servers and a UAT environment as well. Am I correct in my understanding, and what methodologies can I use to justify the cost of upgrading?

    Read the article

  • Is the science of Computer Science dead?

    - by Veaviticus
    Question : Is the science and art of CS dead? By that I mean, the real requirements to think, plan and efficiently solve problems seems to be falling away from CS these days. The field seems to be lowering the entry-barrier so more people can 'program' without having to learn how to truly program. Background : I'm a recent graduate with a BS in Computer Science. I'm working a starting position at a decent sized company in the IT department. I mostly do .NET and other Microsoft technologies at my job, but before this I've done Java stuff through internships and the like. I personally am a C++ programmer for my own for-fun projects. In Depth : Through the work I've been doing, it seems to me that the intense disciplines of a real science don't exist in CS anymore. In the past, programmers had to solve problems efficiently in order for systems to be robust and quick. But now, with the prevailing technologies like .NET, Java and scripting languages, it seems like efficiency and robustness have been traded for ease of development. Most of the colleagues that I work with don't even have degrees in Computer Science. Most graduated with Electrical Engineering degrees, a few with Software Engineering, even some who came from tech schools without a 4 year program. Yet they get by just fine without having the technical background of CS, without having studied theories and algorithms, without having any regard for making an elegant solution (they just go for the easiest, cheapest solution). The company pushes us to use Microsoft technologies, which take all the real thought out of the matter and replace it with libraries and tools that can auto-build your project for you half the time. I'm not trying to hate on the languages, I understand that they serve a purpose and do it well, but when your employees don't know how a hash-table works, and use the wrong sorting methods, or run SQL commands that are horribly inefficient (but get the job done in an acceptable time), it feels like more effort is being put into developing technologies that coddle new 'programmers' rather than actually teaching people how to do things right. I am interested in making efficient and, in my opinion, beautiful programs. If there is a better way to do it, I'd rather go back and refactor it than let it slide. But in the corporate world, they push me to complete tasks quickly rather than elegantly. And that really bugs me. Is this what I'm going to be looking forward to the rest of my life? Are there still positions out there for people who love the science and art of CS rather than just the paycheck? And on the same note, here's a good read if you haven't seen it before The Perils Of Java Schools

    Read the article

  • How to dissuade a customer who just learned a technology and wants to use it everywhere?

    - by MainMa
    My customer recently discovered what is URL Rewriting, without completely understanding what it is, how it works and the pros and cons of it. Now, he asks for lots of strange changes in actual requirements of current projects and changes in old projects in order to implement what he believes is URL Rewriting. On one hand, I'm annoyed being asked to do things which doesn't make any sense instead of doing real work. On the other hand, I can't tell my customer that he doesn't understand anything in the subject despite his interest in it. I think many people have had situations when their manager or their customer just learned a new buzzword or a new technology, and he loved it so much than he wanted to use it in every project, everywhere, rewrite the whole codebase just to use this new thing, etc. Also, I've recently read something related on Programmers.SE where people told about their experiences when there was a huge buzz around XML, and some managers would ask to introduce XML in every project just to show to everyone that they have used it. So those who have been in similar situation, how have you managed it?

    Read the article

  • Inspiring the method of teaching. Example- C++ :)

    - by Ashwin
    A year ago I graduated with a degree in Computer Science and Engineering. Considering C++ as the first choice of programming language I have been in the process of learning C++ in many ways. At first - five years back - I had many conceptions, most of which were so abstract to me. It started when I knew almost everything about Structs in C and nothing about Classes in C++. I went through a great time experimenting them all and learning a lot. I had a hard time evaluating Procedural programming vs Object-Oriented Programming. Deciding when to choose Procedural or Object-Oriented Programming took a great deal of patience for me. I knew that I cannot underestimate any of these Programming styles... Though Procedural programming is often a better choice than simple sequential unstructured programming, when solving problems with procedural programming, we usually divide one problem into several steps in order regarded as functions. Then we call these functions one by one to get the result of the problem. When solving problems with Object Oriented Priciples we divide one problem into several classes and form the interaction between them. Evaluating these two at the beginning (as a learner) required a lot of inspiration and thoughts. Instructing to think step by step. Relative concepts to understand deeply. Intensive interests to contrast both solving in both POP and OOP. If you were ever a mentor: What ideas/methods would you teach to students in which it will Inspire them to learn a programming language (in general, computer sciences)?

    Read the article

  • How do I make my customers not like me too much?

    - by fuzzbone
    In 2004 I went to work for a consulting firm because I like variety, challenges, working with new technologies, etc. However, I've been a developer for 25 years - and spent the majority of my career as a direct-hire (12 years) then as an independent consultant for another 3 years (ah the DotCom bubble!) for one firm. So my instincts are more like a good internal developer than a consultant. My problem is what I call the "catch-22" of consulting. You go into consulting because you want to work at a lot of different engagements, but if you do a really good job your clients never want to let you go. And of course the salespeople are happy to keep you billing (and don’t want to alienate a good customer) So my question is – how do I overcome this? I have had some colleagues who had just the right type of “arrogance” (for lack of a better term) that made them initially attractive to some clients, but would grate on them over time – but that just isn’t my style. I want to do good work and be successful for my clients, but be able to “gracefully” move on after a reasonable amount of time.

    Read the article

  • Cloud service and IM protocol advice, for a backend to group chat mobile app

    - by Jonathan
    Overview I’m going to develop an app on Android and iOS. It will allow users to set up group ‘chat rooms’ and talk on chat rooms set up by other users. The service needs to be highly scalable, such that it could accommodate a massive increase in users overnight (we can only dream). Chat requirements The chat protocol used should be flexible: it should allow me to determine who can view/post on ‘chat rooms’ based on certain other factors, as determined by the first poster/creator of the particular ‘chat room’. It should also allow for users to simply install the app and begin using the service, after only providing a simple nickname (which could be changed later). Chat protocol plans Having looked around I think the XMPP protocol is the best candidate. In particular the Multi-user chat extension looks like what I’ll need. Would this be most suited to my requirements, or do you know another potential solution? Cloud service I have been deciding between Amazon Web Services, Google App Engine and Windows Azure. I’m coming to the conclusion that Azure will be best, as it is easier to manage than AWS (ease of scalability will be a key factor in the design), I think it may be less restricted than GAE, plus Azure will soon have toolkits to allow easy interfacing with both Android and iOS phones. Is this the decision you would have made, or would you recommend/look into other cloud services? General project philosophy I have only recently started looking into this project’s feasibility, and am no expert on any of its aspects. So wherever possible I will leave the actual implementations to experts, i.e. choosing a higher-level cloud service, using a well-documented plugin of a, proven reliable, group chat protocol etc. My background I have some programming knowledge from a computer science degree. Main languages I’ve used have been Java and Python, but I don’t want this to affect design decisions for the project. The most appropriate languages for the task should be used, i.e. I don’t mind learning a lot of new skills (my current programming levels are relatively basic anyway). Thank you Thanks for reading, and any advice you have about any aspect would be greatly appreciated :-)

    Read the article

  • How to improve relationships between consultants and staff programmers

    - by Catchops
    I have been a consultant for a small software consulting firm for quite some time now. Our normal business model is not staff augmentation, but such that we find clients who need assistance in building a solution of some kind and then send in a team who can build that solution, work with the existing IT staff, train all involved on supportting that solution, then move on to the next job. We, of course, are still around for any needed ongoing support. We have a great reputation in our area and have been very successful in implementing the solutions that we provide. However, I have noticed a common theme for most of our projects. When we get on-site, there is generally a "stressed" relationship between our team and many of the IT staff currently at the client. I understand completely that there may be some anxiety about our arrival and that defenses can come up when we are around. Many of the folks are understanding and easy to work with, but there are usually some who will not work well with us at all, and who can quickly become a project risk in many ways. We try to go in with open minds and good attitudes, and try NOT to be arrogent or condecending. We generally get deployed when there is a mess to clean up - but we understand that there were reasons decisions were made that got them in the bind they are...so we just try to determine the next step forward and move on. My question is this - I'd like to hear from the IT staff and programmers out there who have had consultants in - what are the things that consultants do that fire up negative feelings and attitudes? What can we do better to make the relationship better, not only in the beginning, but as the project moves forward?

    Read the article

  • How to name a bug?

    - by Pieter
    Bugs usually receive a descriptive name: "That X-Y synchronization issue", "That crash after actions A, B and D but not C", "Yesterday's update problem". Even the JIRA issue tracker has a field "Summary" instead of "Name". In discussing "big" bugs, I actually use JIRA id's to prevent confusion. There's a few restrictions to take into account: When reporting a bug, only the consequence of a bug is known. The root cause might never even be found. Several reported bugs might be found out to be duplicates, or might be completely different consequences of the same bug. In large projects, bugs will come at you by the dozens every month. Now, how would you name a bug? Name them like hurricanes perhaps?

    Read the article

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