WebIDRealm

hi,

i have updated tomcat's WebIDRealm to the latest spec
and set up a test server [1].

there are two links on this server for testing :

1. "OnlyWithCert"    
   requires the user to be in role <http://data.turnguard.com/webid/2.0/Void>
   since every presenter of a certificate is added to this reserved role, everybody
   with a parseable webIDClaim should be able to see this page (some data from your profile will be displayed)
2. "OnlyWithCert and Role X"
   requires the user to be in role <http://data.turnguard.com/webid/2.0/RoleX>.
   You should get an access denied.


- please note that this is now beta (at best) and any pointer, question, comment or wish is really welcome.
- please also note that rdfa support will follow sometimes this week.


the WebIDRealm now

1. is fully SailAPI compatible [2]
   with a simple jndi factory it is possible to use any data-store that has a SailImplementation.
   note : the test server uses a simple file that is imported to an OpenRDF MemoryStore.
   note : the SailRepository is used to lookup roles needed to check tomcat's security constraints in the first place. (see below)
2. supports different modes
   since there is a SailRepository at hand it is now also possible to lookup webIDClaims in that repository.
   2.1. DEREFERENCE_ONLY
        Tries to dereference the WebIDURI over http
   2.2. DEREFERENCE_NO
        Only looks up the WebIDURI in the given SailRepository, making it also possible to use any uri as a WebIDClaim (mailto:.., URNs)
        This could be usefull in case someone wants to use WebID only "internally" without having to publish all its user profiles 
        (we want nsa and cia to use it also, right?)
   2.3. DEREFERENCE_FIRST, DEREFERENCE_LAST 
        first try to dereference and then look into the SailRepository or the other way round.
3. way less interwoven with apache's tomcat (catalina) api.
   i'm trying to make the Realm fully compatible with major servlet containers during the next couple of weeks.
4. capable to bringing important debug information to the user.
   The only way to get more information to the enduser is to create a (Dummy)Principal when something fails during 
   the authentication process. The actual exception is translated to rdf and added to the (Dummy)Principals data,
   making it possible to give the user usefull information why the login didn't work.
   it is best to try this by
   - making your rdf improper (add a slash where no slash belongs and try to login)
   - remove your cert:key from you profile (and try to log in)
   - alter the exponent and modulus
   - remove the exponent or the modulus
   - try it with an expired certificate
   - try it with a certificate that is not yet valid
   - try it with certificate with a webID that is not dereferencable. 
   it is also now possible to construct the webID testcases from these exceptions (which will be done soon)
   ...

wkr http://www.turnguard.com/turnguard


[1] http://webid.turnguard.com/WebIDTestServer
[2] http://openrdf.org



-- 
| Jürgen Jakobitsch, 
| Software Developer
| Semantic Web Company GmbH
| Mariahilfer Straße 70 / Neubaugasse 1, Top 8
| A - 1070 Wien, Austria
| Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22

COMPANY INFORMATION
| http://www.semantic-web.at/

PERSONAL INFORMATION
| web   : http://www.turnguard.com
| foaf  : http://www.turnguard.com/turnguard
| skype : jakobitsch-punkt

Received on Monday, 2 January 2012 12:50:32 UTC