Re: Core services design patern
Re: Core services design patern
- Subject: Re: Core services design patern
- From: Joe Little <email@hidden>
- Date: Fri, 5 Feb 2010 13:30:12 -0800
Replying to myself here for the benefit of all. I'm an idiot. No surprise there.
I've re-dived into my notes and did some research on where things
stand today for all things shib. Not sure if this is worthy of a
presentation or not.
1) OpenSSO can be used to provide either an IdP or SP. You'll need to
have one of these on site, but in general, as app developers, they are
likely already present where you are for you to use.
2) SPs are currently C++ based, and the Java Servlet only (must be
J2EE) version of an SP is forthcoming real-soon-now. If you are only
providing a service and wish to enable logins to external
authentication sources, then yes, you too will want to implement/run
an SP. However, whether a WO house picks the stable RPMs or EXEs
available for the C++ SP or wants to go with OpenSSO(full Sun DS and
J2EE stack) or the J2EE SP is a matter of taste.
3) The simple approach is THE approach. In all cases, your app is
going to use REMOTE_USER in the WOContext. If you go with a servlet
deploy, there is a lot of fun to be had disabling tomcat or similar
auth and getting these values passed to you. If you use
Apache/wotaskd, its slightly less involved. That said, getting _other_
information to your app and/or configuring Apache to handle other
criteria/restrictions is a boat load of joy for all the masochists out
there.
In its simplest form, you'd do this in Apache:
<Location /secure>
AuthType shibboleth
ShibRequireSession On
require valid-user
</Location>
All the federation and who you trust is in your configuration of the
shib module, tied to SAML artifact URLs. If you hate Maven, you'll
likely hate the whole Shibboleth mess even more, as its XML fun for
all.
This is a good concise howto to wrap your heads around it:
http://www.federation.org.au/twiki/bin/view/Federation/ManualInstallSP?skin=print.pattern
For more fun with Apache, you can see where the rabbit hole is heading
to with this:
In .htaccess:
AuthType shibboleth
ShibRequireSession On
require affiliation ~ ^faculty@.+\.edu$
And your SAML:
<Path name=“myapp/secure” requireSession=“true”>
<AccessControl>
<RuleRegex require=“affiliation”
ignoreCase=“true”>^faculty@.+\.edu$</RuleRegex>
</AccessControl>
</Path>
Request a passive login (e.g. initial access to a portal):
response.sendRedirect(
“/Shibboleth.sso/Login?isPassive=1”);
Request a login via client certificate from Ohio State:
response.sendRedirect(
“/Shibboleth.sso/Login” + “?entityID=“ + “urn:mace:incommon:osu.edu”
+ “&authnContextClassRef=“
+ “urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient”);
These were from:
http://www.ja-sig.org/wiki/download/attachments/13567279/Shibboleth+-+JASIG.ppt?version=1
On Fri, Feb 5, 2010 at 10:01 AM, Joe Little <email@hidden> wrote:
> OpenSSO and their ilk come into play if you can't go the apache/shib
> route. This is especially common when you are trying to connect with
> multiple IdPs, say as a hosted service provider that has specific
> parts of the app accessible to only one IdP vs another, or to support
> multiple IdPs at the same time (if that is even possible). I'm
> thinking its still a royal pain to get OpenSSO to do all of this, but
> its sometimes necessary to build this out more finer grain and in-app,
> perhaps with the config/XML stored in the database, then managing
> multiple external modules and text files.
>
>
> On Fri, Feb 5, 2010 at 9:56 AM, Tim Worman <email@hidden> wrote:
>> I guess I have to look at Open SSO. From what time I did spend looking at Shib it didn't appear that any other frameworks would really be necessary.
>>
>> Tim Worman
>> UCLA GSE&IS
>>
>>
>> On Feb 5, 2010, at 9:46 AM, Joe Little wrote:
>>
>>> Sadly I doubt I'd be able to build out a framework by August nor get
>>> the necessary funding to attend WOWODC, but perhaps the following
>>> event? Then again, Tim might be further along. I will start a project
>>> come Sept 1 that will involve OpenSSO for use with Shibboleth for
>>> Stanford that is not WO related, but I'll then be retrofitting most of
>>> my WO projects to use that effort shortly afterwards. I think 2011 is
>>> a safe target date (sadly) for anything from me.
>>>
>>> On Thu, Feb 4, 2010 at 4:02 PM, David Avendasora
>>> <email@hidden> wrote:
>>>> Now this sounds like a great WOWODC talk, especially by someone that has just implemented it!
>>>>
>>>> Dave
>>>>
>>>> On Jan 30, 2010, at 3:09 PM, Tim Worman wrote:
>>>>
>>>>> I'll be implementing shib here for at least one of my solutions in the very near future. UCLA has migrated to it for all web authentication. I'd definitely be interested to see what others have done with it. I'm actually really looking forward to getting it done. It should definitely simplify a lot of the "log in" process as far as my app is concerned.
>>>>>
>>>>> Tim Worman
>>>>> UCLA GSE&IS
>>>>>
>>>>> On Jan 30, 2010, at 9:19 AM, Joe Little wrote:
>>>>>
>>>>>> I've been wanting to get my but off the ground and build out a WO
>>>>>> howto on integrating with Shib. OpenSSO might make it easier, but the
>>>>>> end result is still just getting a REMOTE_USER back that is asserted
>>>>>> to be ok. Authorization levels won't be know, but most store that
>>>>>> in-app (internal) or reference indirectly via LDAP or the methods
>>>>>> noted above.
>>>>>>
>>>>>> On Fri, Jan 29, 2010 at 6:46 AM, Daniel Beatty <email@hidden> wrote:
>>>>>>> Greetings Xavier, Mike, Cheong, and the Practical guys,
>>>>>>> There are two features emerging that kind of like for this idea. One is the CardDAV notion and second is this "assertion authentication" pattern that has been implemented by Mobile Access Service, OpenSSO, and Shibboleth. A link to the CardDAV reference, even if kept semi-private, would be sufficient to have a unique reference to any user to be had. Since both Apple and Amazon seem to be making such a standard available, then it makes sense for authorization.
>>>>>>>
>>>>>>> If the Java OpenSSO (https://opensso.dev.java.net/) libraries can use the assertions found in Shibboleth and Mobile Access environments, then this would be a most useful for a wide spread and deployed WO app.
>>>>>>>
>>>>>>> But, Chuck may already have me on the certified list. Certified for what, don't ask.
>>>>>>>
>>>>>>> Later,
>>>>>>>
>>>>>>>
>>>>>>> Daniel Beatty, ABD
>>>>>>> Computer Scientist
>>>>>>> China Lake Naval Air Warfare Center
>>>>>>> email@hidden
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jan 29, 2010, at 4:35 AM, Xavier Destombes wrote:
>>>>>>>
>>>>>>>> Hello Cheong,
>>>>>>>>
>>>>>>>> Portability isn't a requirement for us, we just need to ensure we're using "standard" like if we use an Open Directory it's not a big deal, we will eventually only have to redo our read/write method to the ldap, but the attributes will be correct.
>>>>>>>> We also have more and more related services, some come directly from OS X Server and some from our apps so being tied to the OS isn't an issue.
>>>>>>>>
>>>>>>>> What you explained also tells me I won't have to deal with security that much if I "forward" this to the ldap;)
>>>>>>>>
>>>>>>>> I'll probably have to dig a little bit more on this to understand how security will be handled for exemple in the following case:
>>>>>>>> -someone trying to log to another user: if the ldap banish it for like 15mn after the 3rd attempt, I have to make sure the ldap get the correct originated IP and not the one from the core web app
>>>>>>>>
>>>>>>>> I've got quite a bunch of things to clarify before actually do it...
>>>>>>>>
>>>>>>>> Thanks for your inputs,
>>>>>>>>
>>>>>>>> Xavier
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Coincidentally, I have completed a small framework on this same request from customer. It is a pure java framework since it is aimed to be portable to any application e.g. Broadvision, WO. Quite similar that it creates new user password, authenticates user/password and returned error messages. It also has the user capabilities on the access module level. I used "Sha-1", and I thought it should be good enough for hash algo. Is it secured enough? Otherwise, I could change to DES/3DES/ MD4/5 etc.
>>>>>>>>> Just 2c.
>>>>>>>>>
>>>>>>>>>>>> I've got multiple web applications that share some common users.
>>>>>>>>>>>> I was thinking about creating a core user application to provide the authentication service. Basically I'd like my "client" applications to forward the login and password to this core user app and get either "succeed" or "fail" (maybe a broader range of fail messages).
>>>>>>>>>>>> I don't really need the entire user to be stored directly in the "client" apps, but I would sometimes need some attributes from the user object.
>>>>>>>>>>>>
>>>>>>>>>>>> My though was:
>>>>>>>>>>>> -to create a framework to store an abstract class for the user
>>>>>>>>>>>> -to extend this class within the core user app (basically just make them non-abstract)
>>>>>>>>>>>> -to use the abstract class in the client apps (and eventually make only a couple attributes non-abstract at that level)
>>>>>>>>>>>>
>>>>>>>>>>>> That way I could make sure my object is really the same throughout the apps, at least they share a commun set of attributes.
>>>>>>>>>>>> A client app could request a login for a user and store only a subset of the user.
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>>
>>>>>>>>> This email sent to email@hidden
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>>
>>>>>>>> This email sent to email@hidden
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>
>>>>>>> This email sent to email@hidden
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden