|
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.
>
>
******************************************************************
>
*********
>
|
