Although I use the powerbook for just about everything these days, it still lacks software that I need, such as digital mapping. You can run Anquet Maps on Virtual PC but you can’t use the GPS as Virtual PC doesn’t support USB properly. So I still need the PC. It doesn’t have a wireless card, just an ethernet which I added, to back it up to the big Lacie disk the powerbook is using. I blogged this here.

I’ve now decided to share the Mac’s Airport internet connection with the PC via it’s Ethernet card. Here’s how:

On the Mac, go to System Preferences -> Internet & Network -> Sharing.
Click on the Internet tab.
Where it says “Share your connection from”, I set mine to “AirPort”.
Tick the Built-in Ethernet “On” checkbox.

Your now sharing the Airport connection with the PC via Ethernet. Before it will work though, you have to enable it through your Mac’s firewall if it’s running:

Click on the Firewall tab.
Tick the Personal Web Sharing “On” checkbox.

To allow SSH through the Mac from the PC, e.g. from Putty, you’ll need to add a new rule to the Mac’s firewall:
Click on the Firewall tab.
Click on New.
Under Port Name, choose Other.
For TCP Port Number(s), put in your SSH ports. For me, I use the standard 22 and another secret one! : 22,XXXXX
Ignore the UDP setting.
For Description, add something meaninful for the new rule : SSH from PC
Click OK and that’s the Mac’s firewall open to SSH traffic coming from the PC.

Now, connect the PC’s Ethernet to the Mac’s Ethernet. Make sure you add the new zone the PC detects to any firewall software you’re running on the PC.

One more thing to remember. If you close the the powerbook, although it’s still on, the Airport connection will go into power save and the PC will lose it’s internet connection. So keep the powerbook open while you’re surfing on the PC.

That’s it. Fire up a browser on the PC and surf!

PS. The first thing I did, once released from the shackles of dial-up, was to download Firefox!

Tha e gl?® mhath aiste G?†idhlig fhaicinn air nam Beantann Alba. Rach agus leugh e air-loine!

Aiste G?†idhlig bhon MCofS

Scotland

Santa fights off yobs with tree

Wales

Santas accused of street brawl

New Zealand

Bad Santas run wild in Auckland

Skye Birds

Skye Ferns

Wild Skye

The International Otter Survival Fund

Skye & Lochalsh Local Biodiversity Action Plan

Skye & Lochalsh Upland Paths

Skye Mountain Rescue Team

Portree to Gairloch ferry

The last post on the SAMUEL2 interfaces had the answer staring me in the face all the time! Once you’ve run XMLBeans over the SAML schema, you’re ready to go with SAML functionality, complete and unadulterated. The only problem is, if it’s a problem at all, is that applications that use the generated classes directly are then bound to that version of the SAML schema, as their tightly coupled via the XMLBeans generated classes (xBeans).

So, for best practices, you’re better off with a DAO layer on top of the xBeans, that insulate an application from the shifting SAML sands. It’s a lot of work compared to just providing raw schema functionality but it also lets you add in functionality, such as WS-Security stuff and handy things like saving and loading SAML schema fragments in an implementation agnostic way.

An interesting way to do this is through the XMLBeans Extension Interface facility, where you specify which interfaces each xBean will implement. It’s a bit messy though as each xBean calls out to a static handler, which implements the interface, rather than the xBean implementing it. It’s also not nice to program as, although you’re implementing an interface, you can’t declare this in the implementation! Why? Well, it’s bean based. That crappy ol’ OOP breaker again. e.g.:

public interface BeanExtension {
  public doSomethingWithBean();
}

public class BeanExtensionImpl implements BeanExtension {
  public static doSomethingWithBean(XmlObject xBean) {
  }
}

Wrong! BeanExtensionImpl doesn’t implement doSomethingWithBean(), it implements doSomethingWithBean(XmlObject). It if doesn’t, XMLBeans will barf! XMLBeans “injects” a “ghost” object (the xBean class) when calling the static handler. This breaks the interface, so you can’t declare you’re implementing the interface although you sort of are.

Anyway, the solution was there all along. The XAL is the DAO layer. Instead of a DAO getting it’s stuff from a traditional DB persistence layer, it’s getting it from the xBeans, which are “persisting” SAML as Java objects.

Beul-chainnt na G?†idhlige air BBC Alba

LDAP enabling mvnForum

These notes are for 1.0.0 RC4 update 4. There’s a struts action that handles authentication but it’s not used in this release. Apparently the long term plan is to migrate mvnForum to struts so all this will probably change.

Additional classes

mvnforum/contrib

com.mvnforum.auth.OnlineUserFactoryLDAPImpl
– extends com.mvnforum.auth.OnlineUserFactoryImpl – overrides getAuthenticatedUser()
– adds createUser() method

com.mvnforum.auth.LDAPAuthenticator
– Authenticates against LDAP and provides limited LDAPMemberBean functionality

com.mvnforum.auth.LDAPMemberBean
– Provides LDAP information for a user

com.mvnforum.db.MinervaBean
– Provides JDBC functionality to get a user’s modules

Additional files

WEB-INF/classes/ldap-authenticator.xml
– LDAPAuthenticator config file

WEB-INF/classes/minerva.properties
– Connection parameters for MinvervaBean

Additional libraries

mvnforum/WEB-INF/lib/ldap.jar

Modified files

mvnforum/properties/mvnforum.xml:

<mvnforumfactoryconfig>
  …
  <onlineuser_implementation>com.mvnforum.auth.OnlineUserFactoryLDAPImpl</onlineuser_implementation>
  …
</mvnforumfactoryconfig>

The JSP pages are a bit of a problem as they use the default password field “MemberMatkhau” which gets md5 encrypted by the system. There doesn’t seem to be a way to turn the encryption off.
The workaround is to add a new password field that the system doesn’t know about and so won’t encrypt:

<input type=”password” name=”ldapPasswd” size=”15″ onKeyPress=”checkEnter(event);”>

and change the default password field “MemberMatkhau” to a hidden field and set it to whatever the LDAP password field is:

<input type=”hidden” name=”MemberMatkhau” value=”document.submitform.ldapPasswd.value”>

srcweb/mvnplugin/mvnforum/admin/login.jsp
srcweb/mvnplugin/mvnforum/user/index.jsp
srcweb/mvnplugin/mvnforum/user/login.jsp

From SAML1.1, the following have been carried over to SAML 2.0:

Protocol

AttributeQuery
Now contains an Attribute element as AttributeDesignator has been removed from SAML2. Also, no Resource attribute

Request
This is now an abstract type and isn’t used directly, as in SAML1.1. Instead, specific Requests are used:
AssertionIDRequest
AuthnRequest
ArtifactResolve
ManageNameIDRequest
LogoutRequest
NameIDMappingRequest
SubjectQuery – SubjectQueryAbstractType extends RequestAbstractType

Response
The Response element in SAML2 extends the StatusResponseType and not ResponseAbstractType as in SAML1.1. Previously, it contained a and zero or more elements, now it contains either or elements.

StatusCode
This is the same as in SAML1.1 with the addition of extra top level definitions with the prefix urn:oasis:names:tc:SAML:2.0:status:

StatusDetail
Exactly the same as in SAML1.1

Status
Exactly the same as in SAML1.1

StatusMessage
Exactly the same as in SAML1.1

SubjectQuery
Abstract as in SAML1.1 but in SAML2.0 it extends RequestAbstractType and not QueryAbstractType as in SAML1.1

Replaced:

AssertionArtifact – Artifact ArtifactResolve ArtifactResponse
AuthenticationQuery – AuthnQuery
AuthorizationDecisionQuery – AuthzDecisionQuery
Query
RespondWith

Assertion

Action
Exactly the same as in SAML1.1

Advice
Still has Assertion element but AssertionIDReference has been removed and there is now a choice of different elements: AssertionIDRef, AssertionURIRef, Assertion, EncryptedAssertion AssertionIDReference

Assertion
MajorVersion and MinorVersion attributes have been replaced by the Version attribute.
AssertionID attribute has been replaced by the ID attribute.
Issuer attribute has been removed.
IssueInstant attribute remains the same as in SAML1.1.
Conditions and Advice elements remain and new elements can be added: Statement, SubjectStatement, AuthenticationStatement, AuthorizationDecisionStatement or AttributeStatement

Attribute
In SAML1.1 this extended AttributeDesignatorType, which has now been removed from SAML2.0. Attribute now has it’s own type with completely different attributes for the element.

AttributeStatement
In SAML1.1 this extended SubjectStatementAbstractType. In SAML2.0 it extends StatementAbstractType and now contains an EncryptedAttribute element as well as an Attribute element

AttributeValue
The same as in SAML1.1 but with the addition that it can be nil, to cover the case where the corresponding Attribute is null.

Audience
Same as in SAML1.1 with the addition that it MAY also contain the unique identifier URI from a SAML name identifier that describes a system entity.

Condition
Exactly the same as in SAML1.1

Conditions
The AudienceRestrictionCondition and DoNotCacheCondition elements have been removed.
The Condition element remains the same.
The AudienceRestriction, OneTimeUse and ProxyRestriction elements have been added.
The attributes for the Conditions element remain the same as in SAML1.1

Decision

Evidence
The AssertionIDReference element has been removed.
The Assertion element remains the same.
The AssertionIDRef, AssertionURIRef and EncryptedAssertion elements have been added in SAML2.0

Statement
Exactly the same as in SAML1.1

SubjectConfirmationData
In SAML1.1 this was of type anyType. In SAML2.0 it has it’s own type, which extends anyType and within which any elements from any namespace can be added. It’s much more open in SAML2.0

SubjectConfirmation
The ConfirmationMethod, SubjectConfirmationData, ConfirmationMethod and KeyInfo elements have been removed.
The SubjectConfirmationData element remains the same.
The BaseID, NameID and EncryptedID elements have been added in SAML2.0.
The Method attribute has been added in SAML2.0

Subject
The NameIdentifier element has been removed.
The BaseID, NameID and EncryptedID elements have been added in SAML2.0. These have replace NameIdentifier.

SubjectLocality
This is basically the same as in SAML1.1 but with the attributes renamed:
IPAddress -> Address
DNSAddress -> DNSName

Replaced:

AssertionIDReference – AssertionIDRef AssertionURIRef
AttributeDesignator
AudienceRestrictionCondition
AuthenticationStatement – AuthnStatement
AuthorityBinding
AuthorizationDecisionStatement – AuthzDecisionStatement
ConfirmationMethod
DoNotCacheCondition
NameIdentifier – NameID
SubjectStatement

New for SAML2.0:

Protocol

Artifact
ArtifactResolve
ArtifactResponse
AssertionIDRequest
AuthnContextComparison
AuthnQuery
AuthnRequest
AuthzDecisionQuery
Extensions
GetComplete
IDPEntry
IDPList
LogoutRequest
LogoutResponse
ManageNameIDRequest
ManageNameIDResponse
NameIDMappingRequest
NameIDMappingResponse
NameIDPolicy
NewEncryptedID
NewID
RequestedAuthnContext
RequesterID
Scoping
SessionIndex
StatusResponse
Terminate

Assertion

AssertionIDRef
AssertionURIRef
AudienceRestriction
AuthenticatingAuthority
AuthnContextClassRef
AuthnContextDecl

AuthnContextDeclRef
AuthnContext
AuthnStatement
AuthzDecisionStatement
BaseID
EncryptedAssertion
EncryptedAttribute
EncryptedElement
EncryptedID
Issuer
KeyInfoConfirmationData
NameID
OneTimeUse
ProxyRestriction

Following on from the previous post, I decided to split the XAL interfaces. Each SAML object now implements two interfaces:

• org.guanxi.samuel.xal.XALObject – the base interface that defines the functionality of all XAL objects
• org.guanxi.samuel.xal.saml1_1.protocol.* – defines the functionality of a SAML 1.1 protocol schema object
• org.guanxi.samuel.xal.saml2_0.assertion.* – defines the functionality of a SAML 1.1 assertion schema object
• org.guanxi.samuel.xal.saml2_0.protocol.* – defines the functionality of a SAML 2.0 protocol schema object
• org.guanxi.samuel.xal.saml2_0.assertion.* – defines the functionality of a SAML 2.0 assertion schema object

The SAML 1.1 and 2.0 implementations are separate at the moment. When I’ve looked into 2.0 it might be that I can combine the two based on overlapping interfaces.

So, an implementation of a SAML Request object would be:

The XALObject defines object functionality

public interface XALObject {
  public void inject(Node domNode) throws XALException;
  public Node getDOM();
  public void syphon(File file) throws XALException;
}

The Request interface defines functionality specific to a SAML Request

public interface Request extends XALObject {
  public void addAttributeQuery(AttributeQuery attrQuery);
}

A Request implementation should provide both raw XAL and SAML functionality

public class RequestImpl implements Request {
  …
}

The XAL for SAMUEL is coming along nicely, with the following package structure now in place:

The idea is to use the SAMLFactoryProvider to load a SAMLFactory, which provides SAML schema objects, either empty, ready for building SAML packets, or initialised from existing SAML XML.

A SAMLFactory can either load up a direct implementation of the SAML schema or, in the case of the default XMLBeans SAMLFactory, it loads up a delegation layer which delegates calls to the underlying XMLBeans schema implementation. This is quite a complex implementation of SAMLFactory.

The previous version of SAMUEL could, theoretically, be modified to provide a SAMLFactory and a direct coupling to the schema but that would involve implementing the schema directly. I did this for the SAML2 Metadata but it’s not easy!

XMLBeans provides the complete SAML schema implementation by the following files:

Ant build file

<project name=”SAMLMetadata” default=”all”>
  <taskdef name=”xmlbean” classname=”org.apache.xmlbeans.impl.tool.XMLBean” classpath=”/usr/local/xmlbeans/lib/xbean.jar:/usr/local/xmlbeans/lib/jsr173_api.jar” />

  <!– CLASSPATH –>
  <path id=”classpath”>
    <pathelement path=”/usr/local/xmlbeans/lib/xbean.jar” />
    <pathelement path=”/usr/local/xmlbeans/lib/jsr173_api.jar” />
    <pathelement path=”lib/saml-2.0.jar” />
  </path>

  <!– Specifying a schema directory instead of a schema file will pick up the .xsdconfig file –>

  <target name=”saml1.1″>
    <xmlbean schema=”xsd/saml/1.1″
             download=”true”
             srcgendir=”beansrc-saml1″
             destfile=”lib/saml-1.1.jar”
             classpath=”/usr/local/xmlbeans/lib/xbean.jar:/usr/local/xmlbeans/lib/jsr173_api.jar”>
    </xmlbean>
  </target>

  <target name=”saml2.0″>
    <xmlbean schema=”xsd/saml/2.0″
             download=”true”
             srcgendir=”beansrc-saml2″
             destfile=”lib/saml-2.0.jar”
             classpath=”/usr/local/xmlbeans/lib/xbean.jar:/usr/local/xmlbeans/lib/jsr173_api.jar”>
    </xmlbean>
  </target>

  <target name=”guanxi”>
    <xmlbean schema=”xsd/guanxi”
             download=”true”
             srcgendir=”beansrc-guanxi”
             destfile=”lib/guanxi-sp-beans.jar”>
      <classpath refid=”classpath”/>
    </xmlbean>
  </target>

  <target name=”all” depends=”saml1.1,saml2.0,guanxi”/>

</project>

saml.xsdconfig

<xb:config xmlns:xb=”http://xml.apache.org/xmlbeans/2004/02/xbean/config”
           xmlns:samlp=”urn:oasis:names:tc:SAML:1.0:protocol”
           xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion”
           xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”
           xmlns=”http://www.w3.org/2001/XMLSchema”>

  <xb:namespace uri=”urn:oasis:names:tc:SAML:1.0:protocol”>
    <xb:package>org.guanxi.samuel.xal.schemaimpl.xmlbeans.saml_1_1.protocol</xb:package>
  </xb:namespace>

  <xb:namespace uri=”urn:oasis:names:tc:SAML:1.0:assertion”>
    <xb:package>org.guanxi.samuel.xal.schemaimpl.xmlbeans.saml_1_1.assertion</xb:package>
  </xb:namespace>

  <xb:namespace uri=”http://www.w3.org/2000/09/xmldsig#”>
    <xb:package>org.guanxi.samuel.xal.schemaimpl.xmlbeans.saml_1_1.w3</xb:package>
  </xb:namespace>

  <xb:namespace uri=”http://www.w3.org/2001/XMLSchema”>
    <xb:package>org.guanxi.samuel.xal.schemaimpl.xmlbeans.saml_1_1.w3</xb:package>
  </xb:namespace>

</xb:config>