3. How is the Principal to Role Mapping Handled ?

GlassFish provides facilities for doing this. It is an entiretopic of its own and most people writing WebApplications forGlassFish know how to do this. The following two links have moredetails on this topic.

http://blogs.sun.com/monzillo/entry/principal_2_role_mapping_and

http://docs.sun.com/app/docs/doc/819-3672/beacr

4. What are the Configuration Steps to Enable ProgrammaticAuthorization

In general when making use of NON-SAML Security Mechanism(s) such asUsernameToken, X509Certificate or Kerberos Tokens, the only thing oneneeds to do before he/she can use the Programmatic Authorization API isto make sure steps 2 and 3 above are taken care of (i.e define yourRoles and Define your Principal to Role Mapping). This is because theMetro runtime can automatically establish the incoming Caller Identityfor those Mechanisms. However for SAML based Mechanisms theRuntime would not know what is the incoming Caller Identity since thePrincipal and other Authorization Information would generally be insidethe SAML Assertion sent by the Caller and only the WebService candecide what is the exact caller Identity.

So in Metro 1.3 we have extended the SAMLAssertionValidatorinterface to allow the SEI developer to decide and set the principalthat identifies the incoming caller (presumably after analyzing thecontents of the incoming SAML assertion and any other additionalContext). The new interface iscom.sun.xml.wss.impl.callback.SAMLValidator interface. The samplebelow would show an implementation of the interface.

5. How do i Integrate my UsernameToken/CertificateAuthentication in Metro WebService with GlassFish Realms

When using UsernameToken or Certificate based scenarios, one can makeuse of GlassFish Realms, and the associated assing-groupsfacilities to automatically assign additional group membershipsto the incoming Caller. These Groups may then be mapped to Rolesas appropriate within sun-web.xml or usingdefault-principal-to-role-mapping feature of GlassFish (see 3 above).

So a WebService making use of UsernameToken authenticationmechanisms can declare the realm against which the username/passwordneeds to be authenticated. The realm declaration however is notunder the element of web.xml as definedin JavaEE. This is because the login-config element was meant forWebApplications.

FORMLDAPRealm/pages/logon.jsp/pages/logonError.jsp

Specifically the auth-method is required inside a login-configand those methods FORM/BASIC etc are not applicable for SOAPMessage Security. So the alternative way to define the realm foryour webapplication is currently to package your WAR file into an EARand define the realm inside sun-application.xml. Netbeans can beused to easily create a Web Application Packaged as an EAR. And thenone can add a sun-application.xml file defining the realm. See examplebelow.

In the above sample i have defined the realm to be the JDBCRealmsupported by GlassFish.

Note: The SailFin Builds of GlassFish support a newJDBCDigestRealm. However the PasswordDigest AuthenticationMechanism of Metro is still not integrated with theJDBCDigestRealm. This would come soon in near future releases of Metro.

6.Sample SEI Impl showing Programmatic Authorization

As a sample this document makes use of the style="font-weight: bold;">SAML Authorization over SSL security mechanism configured from NetBeans for my Metro 1.3WebService. The idea is that the NameIdentifier of the SAMLAssertion would be used to decide the incoming Caller Principal. The sample defines two roles "doctor"and "patient". Here is howthe web.xml would look like :

In this sample, for the sake of simplicity, i would just
make use of explicit principal to role mapping in
sun-web.xml. This approach is cumbersome and does not scale as
the number of different registered users of a WebService can easily run
into thousands. Please see the other approaches of doing P2R
Mapping as described by the links in section 3 above. So here is my
sun-web.xml

Here is the code that i have implemented inside my SAMLValidator.
The main logic here is to look for a NameIdentifier with name
style="font-weight: bold;">DrRobert and only if that is
found i would set a Principal as understood by glassfish. Note
that the sample uses a Proprietary GlassFish Principal Class. In near
future release of Metro we would add a Metro API that would allow
setting the principal inside the Subject. The Subject is the one
that the GlassFish Container would use for subsequent authorization
decisions. Below is the simplistic code of my SAML Validator. In
reality the decision code inside the SAMLValidator can be complex,
making use of other context information and may lookup some databases
etc.

And Finally here is the code in my SEI implementation class where i am
querying the Roles of the Incoming Caller :

package test;

import javax.annotation.Resource;

import javax.jws.WebMethod;

import javax.jws.WebParam;

import javax.jws.WebService;

import javax.xml.ws.WebServiceContext;

@WebService()

public class SAMLService {

@Resource

private WebServiceContext context;

/**

* Web service operation

*/

@WebMethod(operationName = "operation")

public String operation(@WebParam(name = "parameter")

String parameter) {

//TODO write yourimplementation code here:

Boolean bool =context.isUserInRole("doctor");

System.out.println("context.isUserInRole("doctor")=" + bool);

Boolean isPatient =context.isUserInRole("patient");

System.out.println("context.isUserInRole("patient")=" + isPatient);

return "Hello " + parameter;

}

}

7. SAMPLE WebService Client

The WebSerivce Client would need to use SSL, this can be achieved by
specifying a https url for retrieving the WSDL, when creating the
WebServiceReference within NetBeans (For example, in this sample i
specified, https://somehost:8181/SAMLSSL/SAMLServiceService?wsdl). The
WebService Client would need to implement the SAML CallbackHandler
which would send a SAML Assertion containing NameIdentifier as
"DrRobert". Here is the code for the Client Side SAML
CallbackHandler, which creates a Dummy SAML Assertion for now. In
reality the CallbackHandler can authenticate to a Security Token
Service to obtain a Token.

Here is the Metro configuration file for the WebSerivce Client
. Note the configuration of SAMLCallbackHandler (Note :
this step can be achieved within Netbeans by specifying the name of the
SAML CallbackHandler)

classname="test.MySAMLCBH"/>

So when i run the client, here is what is printed out of the Role Query
on the Server (as seen in GlassFish server.log file)

Future

We are currently working on Support for Java EE 5 defined
Declarative Authorization based on Annotations @RolesAllowed,
@DeclareRoles etc. for Servlet based webservices. Note that
Declarative method level authorization using these annotations is
already supported in GlassFish for EJB WebServices.

Comments

by kumarjayanti - 2008-12-01 00:49

You could split your processing. The Validation of the SAML assertion IMO should happen inside the Validator so that you can reject an invalid assertion thereby disallowing the invocation of the business method.
Since passing over the assertion again inside the business method is expensive, it is best you gather credential information required to authorize the request within the validator.

Hi,
you wrote "In near future release of Metro we would add a Metro API that would allow setting the principal inside the Subject. " Has there been an update on this yet, or is still the recommendation using com.sun.enterprise.deployment.PrincipalImpl?
Thanks,
Martijn

Kumar, just to confirm, in cases where permission to execute a web service call is dependent both on an attribute defined in the SAML token and a value within the SOAP body, the validation should occur within the service implementation bean and *not* the SAMLValidator, correct?
For example, if I have a WithdrawMoneyFromAccount web service operation, and if the amount to be withdrawn is greater than $100 the person making the request must have the Manager attribute defined in his SAML token ($100 or less anyone can make the SOAP call), where should this be checked--as far as I can tell, I *cannot* read the SOAP body from within the SAMLValidator, so I will need to read the SAML token within the SIB[1], correct? Thanks!
[1] http://weblogs.java.net/blog/kumarjayanti/archive/2007/12/accessing_the_...

The Signature of the SAML Validation Method shows :
public void validate(XMLStreamReader arg0, Map arg1, Subject arg2) throws SAMLValidationException
So you are expected to throw a new SAMLValidationException whenever the validator finds something wrong with the Assertion. The sample code i have pasted actually throws SAMLValidationException.
As for what all things need to be checked, the answer is everything other than the SAML Enveloped Singature. The Enveloped Signature for a HOK assertion is verified by the runtime before it calls the Validator.
As for the arguments, here is what the javadocs say :
validate
void validate(javax.xml.stream.XMLStreamReader assertion,
java.util.Map runtimeProps,
javax.security.auth.Subject clientSubject)
throws
SAMLAssertionValidator.SAMLValidationException
Parameters:
assertion - The assertion as an XMLStreamReader
runtimeProps - the runtime properties associated with this request
clientSubject - the Subject of the sender which can be updated after validation with principal/credential information
Throws:
SAMLAssertionValidator.SAMLValidationException
The javadocs are pushed here :
https://xwss.dev.java.net/servlets/ProjectDocumentList?folderID=5501&exp...
If you download xwss-3.0.zip it would also have the Javadoc bundle inside it.
I will try and see if i can publish it on the XWSS homepage instead of having people to download the entire xwss bundle.
Thanks.

It would be nice Kumar if you would elaborate a bit on the SAMLValidator[1] in a future posting (I also asked Jiandong for help here)--namely, what are the different types of things a SAMLValidator can/should check for, and what are the exceptions that should be thrown (or other processing that needs to be done) for the different types of validation errors, and what processing should be done if everything is OK? (Your example is GlassFish-specific--although I'm not sure what "arg2" represents--but I'm looking for what generally should occur in this method if a SAML token passes validation--is it sufficient to just return with no exceptions thrown?)
[1] http://www.nabble.com/Need-SAMLValidator-example-tt20558503.html#a20558503

Wow, the best JAAS tutorial.. I have seen.. Well done. I am actually looking tutorials like this which give brife idea about JAAS and how to authorize is what most of the tutorials lack. I have one question to ask is How do we do authorization using Messege authentication over SSL ?