Yes, that is the correct way. The principal should always be retrieved from the AuthenticationService. Instead of injecting the AuthenticationService, though, a cleaner approach is to create a UserService from which you can obtain the principal and other authorization stuff. The UserService uses the AuthenticationService to get the principal and for example cast it to the proper type if you use a custom principal. You can see it in TempHire, although TempHire doesn't actually use the UserService anywhere yet, but it shows the idea. The idea of this approach is to cleanly separate authentication from authorization.
The interface looks like this:
public interface IUserService { bool IsLoggedIn { get; }
UserPrincipal CurrentUser { get; } }
And the implementation like this. The custom AuthenticationService acts in both capacities, but from the consumption perspective, the two concerns are separated.
[Export(typeof(IAuthenticationService))] [Export(typeof(IUserService))] [PartCreationPolicy(CreationPolicy.Shared)] public class TempHireAuthenticationService : AuthenticationService, IUserService { #if FAKESTORE public TempHireAuthenticationService() { Configure(config => config.WithConnectionOptions(ConnectionOptions.Fake.Name)); } #endif
#region IUserService Members
public UserPrincipal CurrentUser { get { return Principal as UserPrincipal; } }
#endregion
protected override void OnLoggedIn() { base.OnLoggedIn(); EventFns.Publish(new LoggedInMessage(CurrentUser)); }
protected override void OnLoggedOut() { base.OnLoggedOut(); EventFns.Publish(new LoggedOutMessage()); } }
|