[Jhs-leads] RE: Update of the SSO,
in regards to the SRF application-
Kirkpatrick, Ivan
Ivan.Kirkpatrick at dep.state.fl.us
Tue Nov 15 10:38:20 EST 2005
The WacaHandler was updated two weeks ago by Philip Manual working on the
DslFspli application to include a selector for each of the environments,
Demo, Integration PreProduction and Production, based on hostname. So
depending on the host the JhsSso is deployed on it will select the
appropriate waca data base instance. The Constants class in EntComp contains
the db urls and if these are not correct we will adjust them when so advised.
I do note that it would be helpful to have the WacaHandler log which url it
is using at the time the selection is made..
-----Original Message-----
From: Williford, April
Sent: Tuesday, November 15, 2005 10:24 AM
To: Kirkpatrick, Ivan
Cc: DBA; jhs-leads at lists.dep.state.fl.us; Java Team; Keyt, Bob; Gorton,
Donna; Davis, Dixie; Clay, Linc
Subject: RE: [Jhs-leads] RE: Update of the SSO,in regards to the SRF
application-
Ivan,
Is SSO still hitting oradev for authentication? Will it be hitting
orabeta/prod in the future based
on which server it's on?
Thanks,
April
-----Original Message-----
From: jhs-leads-bounces at lists.dep.state.fl.us
[mailto:jhs-leads-bounces at lists.dep.state.fl.us]On Behalf Of Kirkpatrick,
Ivan
Sent: Monday, November 14, 2005 10:22 AM
To: Keyt, Bob
Cc: DBA; UNIX; jhs-leads at lists.dep.state.fl.us; Zimmerman, Jeffrey; Java
Team; jhs-pms at lists.dep.state.fl.us
Subject: [Jhs-leads] RE: Update of the SSO,in regards to the SRF application-
I can see that some clarifications are in order.
The current SSO available within the JHS is an implementation of the
Centralized <https://clearinghouse.ja-sig.org/wiki/display/CAS/Home>
Authentication Server (CAS) from Yale University. I have been updating the
JhsSso project at http://epic52.dep.state.fl.us/jhs-sso/ and will include
this and your questions as part of the information on the project web site.
The JhsSso ticket is never saved to the hard drive of any computer in so far
as I know. The ticket is specific to the user's browser session only. If
the browser is closed the ticket is removed from the user session
information. Later versions of the MS windows OS's incorporate kerberos
authentication with MS Active Directory (AD) at login time. This
information, a ticket, is loaded into Internet Explorer when it is started
up.
The CAS only supports authentication. Authorization is an application
specific consideration. We can authenticate now against the Waca user tables
in the databases and working with Brandon has led me to believe that we can
authenticate against the MS AD user store via the kerberos ticket in the IE
Browser eventually. This is different though than is currently implemented
in that using the MS AD involves getting the user's ticket from the Operating
System once the user has logged on to the local network. In this respect it
is considerably different than web enabled SSO. Obviously MS likes to keep
one tied to the OS and not simply a browser session. This is part of the
reason for the disparity in authentication techniques.
The authorization element of Single Sign On presents another aspect of this
effort. From an Enterprise point of view, we would like to offer a single
unified approach for all applications to utilize in determining any user's
accessibility to and roles within any Jhs hosted applications. Rather than
have each application write code to define a User Object and collect
applications and roles for each in various databases we would prefer it be
done one time in one set of User components for all applications within the
Jhs.
I have discussed this architecture with Dannny and Brandon and we all
basically agree on an approach. I have been working on implementing this in
a manner that is useful to all applications. Unfortunately demands on my
time preclude any rapid prototyping. It is quite easy though for others to
contribute to this effort. The architecture is in place and the code is
being implemented. The current status of these components is found online at
http://epic52.dep.state.fl.us/ent-comp/ The specific files involved are User,
UserImpl, UserFactory, AbstractEntUser, UserTest, Application, Role and a
handful of others. None of these are particularly difficult to write and are
intended to facilitate cooperative and iterative development.
Regarding the remainder of your questions, Standard functionality provided
by CAS requires the Client side of the CAS to perform a validation of the
ticket returned by the CAS server. This works fine on the Pre-Production
server but for reasons that are still being investigated it does not seem to
work on the Integration machine. The server side code works fine on all
machines. So it seems we have some additional troubleshooting to perform.
The architecture described above is specifically designed to allow for any
user to have controlled access to multiple applications and multiple roles
within any one or all of the applications. Our intent is to have this
collection of applications and roles available to the Jhs applications
regardless of where the information is stored, be it on the MS AD or Waca or
any other place. Adding in additional information stores is fairly simple
although not trivial. So far Waca seems to suit most applications and I have
yet to be advised of formal requirements in addition to these. My suggestion
is that if any application requires additional functionality it is most
easily accommodated within the current architecture with some guidance.
The JhsSso is deployed on the Pre-Production machines and undergoing testing
as part of the DslFspli and other applications. We expect to have the
current version deployed to Production in concert with the production
deployments of the applications that require it.
All documentation and project information is available on the Jhs web site or
from links found there. I have tried to collect and organize it
appropriately. The main web site is http://epic52.dep.state.fl.us/jhs-sso/
and the example Jhs client application is at
http://epic52.dep.state.fl.us/sso-exp/ The authentication portion of the Sso
as previously noted is part of the EntComp at
http://epic52.dep.state.fl.us/ent-comp/.
I will add the above information to the web sites noted as soon as I can.
-----Original Message-----
From: Keyt, Bob
Sent: Monday, November 14, 2005 8:39 AM
To: Kirkpatrick, Ivan
Cc: Zimmerman, Jeffrey
Subject: FW: Update of the SSO, in regards to the SRF application-
Ivan,
I need your confirmation and clarifications to be completely comfortable with
our approach.
1. Is the SSO summary below correct? Please provide corrections and
clarifications as appropriate. I would understand better if you would insert
(SSO) or (SRF) behind the words "it" and "application" in the Summary. Right
now, it looks like the SSO will only verify the user identifier/password and
save a "ticket" for the hard drive. Is remaining security functionality, such
as checking the ticket, left to the (SRF) application?
2. Will the SSO support multiple concurrent applications roles? Specifically,
can an individual have multiple roles for one application enabled by one
sign-on?
3. What is the SSO project timeline (design, development, UAT,
implementation)?
4. Where is SSO project documentation located, such as the needs evaluation
and detailed specification?
We really appreciate your assistance!
Dan,
Since we plan to create a "black box" substitute for the SSO, do we have the
specifications (classes, methods, data) to seamlessly (NO or minimal code
changes) replace our "black box" with SSO when it becomes available for
testing and implementation?
I must remind you that the approved SRF-I2 project timeline requires
construction testing to be complete the first week of June 2006 (the rest of
June is QA reviews and Approvals) and User Beta Testing (UAT) in July 2006.
That means we need an implementable security solution by April 2006, at the
very latest!
Bob Keyt, PMP(R)
Senior Principal Consultant/Project Manager
Department of Environmental Protection
2600 Blair Stone Rd, MS 3500
Tallahassee, Florida 32399-2400
-----------------------------------------------------------
Work: (850) 245-8674 (internal 5674)
Cell: (850) 545-4897
Please note: Florida has a very broad public records law. Most written
communications to or from state officials are public records and may be made
available to the public or media upon request. This e-mail communication,
your reply, and future e-mails to my attention may therefore be subject to
public disclosure.
_____
From: Zimmerman, Jeffrey
Sent: Thursday, November 10, 2005 4:02 PM
To: Keyt, Bob
Cc: Bergenroth, Brandon; Carney, Christopher; O'Donnell, Danny; Worley,
Robert; Etter, Kathleen
Subject: Update of the SSO, in regards to the SRF application-
Good afternoon, Bob,
Both Brandon and Danny O'Donnell have met with Ivan independently to discuss
the implementation of the proposed SSO. It seems that there has been some
progress made in this arena and we wanted to give you a brief update as to
the information we received.
Summary of how SSO was explained to work:
1) When a user opens a browser and goes to a web application that utilizes
the SSO, it looks for a ticket on the user's hard drive.
2) If the user has a valid ticket, go to step #4.
3) If user does not have a valid ticket, it is taken to the SSO screen,
where they are prompted to input a user name and password. A successful
username/password combination will then create a ticket and place it on the
user's hard drive.
4) The application verifies the ticket, located on the user's hard drive.
Information is taken from the ticket and enables creation of a user object
from the enterprise component. This object will contain the application
information which will be used by the application. If the user does not have
the proper privileges (roles) for the application then user may be denied
entry to some or all of the application (and/or certain functionality).
Otherwise, the user is allowed to have access to the application with
whatever privileges and access that is granted to that individual for their
role(s) as they move through the application.
The solution for how SRF will proceed:
The WRMITS team will create a temporary facsimile of the proposed SSO
component. This will act as a temporary placeholder and will allow us to
continue with our development. Upon the SSO's completion, it will be
integrated into our current framework. Since the foundational framework will
be created to handle the parameters of the proposed SSO, transition to the
enterprise wide component should not be an arduous task.
Since this is one of our highest risk factors, the SSO will need to be stable
and in place by the time construction is complete, in the spring to early
summer of this year. If the SSO is not in place by that time, it is safe to
say that this risk has unfortunately come to fruition and that we need to
find an alternate means of securing the SRF application.
Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.dep.state.fl.us/pipermail/jhs-leads/attachments/20051115/225ef832/attachment.html
More information about the Jhs-leads
mailing list