Update on Fish and Game Accounts for Developers

Fish and Game Accounts is now fully in production, albeit not advertised so our user base is predominantly internal and Idaho Transportation Department Users of our Roadkill App.

NOTE: Some background reading on Fish and Game Accounts may be found in the post How Fish and Game Accounts Secures Your Application.

As of this post we have 129 Users in 147 Groups.  That is correct, we have more organizations than we have people, but if you think about any non-hierarchical network model (or all the how many more chiefs we have than indians) this won't be too surprising.  As we start advertising our site publicly, the number of Groups will level off, while the number of Users will start to increase exponentially.  I'll predict that if I write a zeitgeist for Fish and Game Accounts 2011 we'll end with 3,000 Users and 200 Groups.

That's nice, but I'd really like to know how to use it.

For Developers I've just completed a small little App that will build your web.config for you with a couple clicks.  This will allow you to secure a directory, files or resources using IIS7.  No programming required.  It's called Authorization Builder and you'll find it in the sidebar of Fish and Game Accounts if you are authenticated.

And How

1. Check the Roles that you want to allow access.


2. Copy the generated web.config to a file called web.config in the folder that you want to secure.


3. There is no Step 3.

But I'm a Programmer not a Monkey!

Ok, I get it.  You write rich applications and you want to decide what parts of what resources on a page are visible and only show certain links to certain people.  We can do that.  Dividing your application into folders and securing with IIS7 is more fail safe, but hey, at least it's out of my hands now (rubs hands together mischievously).

And How

Method 1: Web.config Location Paths

You can still use the web.config, but call out specific pages:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

    <location path="foldername/mypage.html">

        <system.web>

            <authorization>

                <allow users="idfg" />

                <deny users="*" />

            </authorization>

        </system.web>

    </location>

</configuration>

    

Method 2: Users and Roles in .Net

You can access the authorization elements via .Net.  There are lots of examples online for this and what is available depends on whether you are on a page or in code, but intellisense supports it, and it is fairly straightforward.  For example here is a small fragment (in C#.Net) that controllers what roles can see what links in a list:

 <ul>   

  <li><a href=""home">Home</a></li>

  <% if (Request.IsAuthenticated) { %>

    <li><a href="myprofile">My Profile</a></li>

  <% } else { %>

  <li><a href="register">Register</a></li>

  <li><a href="reset">Forgot Password?</a></li>

  <% } %>

    <li><a href="about">About</a></li>

  <% if (Roles.IsUserInRole("admin")) { %>

    <li><a href="admin/management">Administration</a></li>

  <% } %>

  <% if (Roles.IsUserInRole("idfg-ggHQInfoSys") || Roles.IsUserInRole("idfg-ggIFWISAdmin")) { %>

    <li><a href="authbuilder">Authorization Builder</a></li>

  <% } %>

</ul>

This is just one simplistic example.

Method 3: .Net is for Silly Persons

You're not a fan of M$.  Ok, we can still dance.  Because we are using IIS7 the User information is available by accessing the Server Variables and with the Accounts API you can access roles and profile information. Here's some examples:

• Using Accounts with Classic ASP


• Using Accounts with PHP


• Using Accounts with JQuery

Additionally, there is a number of protected webservices for synching groups with other IDFG applications.  Please contact me for details.  And if you want to secure a Click-Once Application, contact me for that too because it's ugly enough to warrant a future blog post.