|
Nisha,
As I mentioned below, when
using WS-Security, you must write a header processor (an Axis handler) that
takes the SAML token and maps it to a principal, and then use JAAS to check
authorization.
I'm assuming that your Web service is running in Axis server. You
use JAAS as the API to interface with your existing security infrastructure
(whatever that is).
Anne
thanks so much for all that information anne.. helps me to a great extent
to have your input!
but what would the required components be if i were to start
implementing a webservices authentication module (considering ofcourse that
i've decided to use SAML within WS-Security for authentication and JAAS for
authorization like you'd mentioned?)
i mean what are the servers i would need? what would fit where? basically
an architecture of necessary components?
where exactly would Axis fit in here as a SOAP server? (to get a
handle of the received SOAP message and parse it? so that would include the
header processor for the WS security header like you'd mentioned?) and then
use JAAS for the authorization thereof? (within Axis?)
regards,
nisha
-----Original Message-----
From: Anne Thomas
Manes [mailto:[EMAIL PROTECTED]
Sent: Mon 3/17/2003 7:30 PM
To: [EMAIL PROTECTED]
Cc:
Subject:
RE: Authorization using WS security and SAML
SAML provides a standard XML format to express and exchange
security
assertions. Assertions come in three flavors: authentication,
authorization,
and attributes. You get these assertions from some type of
trust authority,
such as a single sign-on service or an entitlement
service. SAML defines the
protocols (SOAP messages) that you use to get
these assertions.
One of the primary reasons why you might want to
use SAML is to support
single sign-on. But if you don't have a SAML
authentication authority, then
you probably don't want to use
SAML.
In WS-Security speak, a SAML assertion is an XML security
token. Once you
have a SAML token, you can relay that security
information in your SOAP
messages (in a SOAP header) using WS-Security.
WS-Security also supports a
number of other security tokens, such as
X.509 certificates, Kerberos
tickets, XrML tokens, XCBF tokens, or a
simple userID/password token.
But you don't need to use either SAML
or WS-Security to implement
authentication or authorization. There are a
number of authentication
mechanisms that you can use: HTTP Basic, HTTP
Digest, SPKM (X.509
certificates). The challenge that you need to solve
is mapping these
transport-level authentication mechanisms to a security
principal within
your environment. You will need to implement a
transport-level interceptor
to capture the authentication information and
map it to a principal. Then
you need to carry that context with your
request until you get to the
service dispatch point, at which point you
can use JAAS to determine if that
principal is authorized to access the
requested service.
If you're using WS-Security, then you must write a
header processor that
takes the security token and maps it to a
principal, and then use JAAS to
check
authorization.
Anne
> -----Original Message-----
>
From: Nisha Menon [mailto:[EMAIL PROTECTED]]
>
Sent: Monday, March 17, 2003 5:25 AM
> To:
[EMAIL PROTECTED]
> Subject: RE: Authorization using WS security
and SAML
>
>
>
> Yip... I get it now...
:-)
>
> Ok so here's the deal...
>
> The SOAP
message that comes in is parsed and the authentication
> information
is extracted. (I guess that module would need to look out
> for a
pattern followed since we'd have to know which standard is being
>
used to pass the authentication information. i.e username/password
or
> certificates or security tokens etc) Depending on that, we'd have
to
> re-route the process to an appropriate authentication module.
Each
> module extracts the required information in it's own way
and
> authenticates the message.
>
> The next step is
authorization. Now this is what I'd be more interested
> in.
>
Once I have the authentication, I need to authorize the SOAP
request.
> Here too SAML can be used to set assertions. And then again
maybe not.
> So I'd have to have separate modules for authorization as
well. Each of
> which relate to internal mappers (what are mappers??
Look up DBs??)
>
> This is the basic requirement. The hassle is,
I'm new to webservices and
> I was wondering what standards, protocols
and APIs I need to work with
> and where they'd fit
in.
>
> As far as I see it, (that may not be seeing
much)
> WS-Security and SAML could be one of the ways to secure a
message and
> that would comprise of one of the many authorization
modules I was
> talking about earlier. So I'd need to extract that
information from the
> SOAP message and work on it. In order to do
that I'd use JAAS APIs? (u
> think?) within which I use OpenSAML to
work on the extraction? (just
> guessing here..) After extraction I
need to map the actors. And that
> should complete the authorization
process.
>
> How does that sound?
>
> Dims:
>
You had suggested TSIK? I gather they're java APIs for SAML etc..
Would
> that replace JAAS in the above picture?
>
>
Regards,
> Nisha
>
>
> -----Original
Message-----
> From: Ricky Ho [mailto:[EMAIL PROTECTED]]
> Sent:
Monday, March 17, 2003 11:40 AM
> To: [EMAIL PROTECTED];
[EMAIL PROTECTED]
> Subject: RE: Authorization using WS security
and SAML
>
>
> I haven't closely track the OASIS
activity. They are supposed to
> standardize how to put a SAML
assertion inside a WS-Security header.
> JAAS is a Java API for doing
authentication and authorization. Compare
> API
> with
protocol is like oranges and apples.
>
> Rgds,
Ricky
>
> At 09:23 AM 3/17/2003 +0530, Nisha Menon
wrote:
> >Ricky,
> >
> >Being new to all of this,
it's been great help so far already! I've
> >been trying to
evaluate the available standards to see what I need to
> >work with
on this module. And from what I've been reading over the
last
>
> >month or so, I'd narrowed down to SAML and
WS-Security on the basis
> >that they work well together and
they're very popular. It'd just been a
>
> >week since I'd
heard about XACML (duh!) and I must admit it had me all
>
>confused! :-) thx for helpin me out there! Ok so you've told me
about
> >what SAML does (and I guess I can use OpenSAML APIs for
development
> >there) but what about WS-Security? Does embedding
SAML assertions into
> >the SOAP Security Header within the
<wsse:Security> tag complete the
> >picture? Also, how does
JAAS compare to all of these standards in
> >authorization? Where
would it fit in?
> >
> >Lotsa questions there! :-(
>
>
> >Regards,
> >Nisha
> >
>
>
> >-----Original Message-----
> >From: Ricky Ho [mailto:[EMAIL PROTECTED]]
> >Sent:
Sunday, March 16, 2003 10:08 PM
> >To: [EMAIL PROTECTED];
[EMAIL PROTECTED]
> >Subject: Re: Authorization using WS
security and SAML
> >
> >
> >SAML is about
specifying the XML format of your authorization decision
> >outcome
(authorization assertion). It also defines a protocol how to
>
>request the assertion. SAML doesn't describe how the decision
should
> >be
> >
> >made. XACML is
attempting to standardize how such decision rules
> >should be
specified. So it is completely solving an orthogonal
>
>problem.
> >
> >I'm not sure how important to
standardize decision making rules because
> >there is NO
"inter-operability" requirement for that. There is NO
need
>
> >to communicating how I made my decision to my
business partners. The
> >value of
> >XACML is
"portability" of my decision criteria across multiple vendor
>
>products. However, "portability" has never been a goal for any
XML
> >standard. It is arguable how important XACML will
be.
> >
> >Best regards,
> >ricky
>
>
> >At 06:38 PM 3/16/2003 +0530, Nisha Menon wrote:
>
> >hi,
> > >
> > >i am trying to create an
authorization module for web services that
> > >is independant
of the application and to authorize i've chosen to use
>
> >
>WS-Security and SAML. would anyone on this list be familiar with
>
> >similar implementation? or
> >have
> > >any
references for the same?
> > >also, how does XACML compare to
SAML?
> > >
> > >thank you,
> >
>
> > >nisha
> > >
> >
>**************************Disclaimer*********************************
>
> >**
> > >*
> > >
> >
>Information contained in this E-MAIL being proprietary to Wipro
>
> >Limited
> >
> > >is 'privileged' and
'confidential' and intended for use only by the
> >
>individual
> > > or entity to which it is addressed.
You are notified that any use,
> >copying
> > >or
dissemination of the information contained in the E-MAIL in any
>
>manner
> > >whatsoever is strictly prohibited.
> >
>
> >
>*********************************************************************
>
> >**
> > >****
> >
>
>
**************************Disclaimer************************************
>
>
Information contained in this E-MAIL being proprietary to Wipro
>
Limited is
> 'privileged' and 'confidential' and intended for use only
by the
> individual
> or entity to which it is addressed.
You are notified that any
> use, copying
> or dissemination of
the information contained in the E-MAIL in any manner
> whatsoever is
strictly prohibited.
>
>
******************************************************************
>
*********
>
|
