Thanks for the info :)
On Dec 25, 12:34 am, "Ryan Shelley" <[EMAIL PROTECTED]> wrote:
> Look into the Provisioning API
> (http://code.google.com/apis/apps/gdata_provisioning_api_v2.0_referenc...)
> - however, the Provisioning API requires a Premier
> account<http://code.google.com/apis/apps/start.html>.
> With the Provisioning API, you can create Google accounts automatically. I
> don't know what your setup is, but there are a number of ways to do this.
> If you have your own custom admin control panel for creating accounts in
> your infrastructure, then you can easily integrate the API into it. Worst
> case scenario, if all you have are logs, you can write a daemon to scan your
> logs for the creation of a new account and call the Provisioning API as
> needed. Alternately, you can upload a CSV file to Google on a daily or
> weekly basis to create new accounts. So you could have your admin control
> panel write out a list of new accounts every day, then someone logs into the
> Google control panel and uploads the CSV file to create their Google
> accounts.
>
> -Ryan
>
> On Dec 24, 2007 1:55 AM, ByteCode <[EMAIL PROTECTED]> wrote:
>
>
>
> > or there is another way that in my application i use google api to
> > also create the user account so that i dont have to manually add the
> > account again in google?
>
> > On Dec 24, 2:46 pm, ByteCode <[EMAIL PROTECTED]> wrote:
> > > Thanks,
> > > so that means i have to add the account two times , 1st in google and
> > > then in my application?
>
> > > Ryan Shelley wrote:
> > > > Yes, that's the possibility - and actually, that's usually how most
> > test
> > > > implementations work. The idea is that Google will delegate
> > authentication
> > > > to you, so it's your responsibility to ensure that the user is
> > properly
> > > > authenticated to your network. If there's a flaw in your application
> > that
> > > > allows a user to authenticate as someone else, then there's the
> > potential
> > > > that an individual could access another user's mailbox. However, this
> > > > "flaw" exists in most (if not all) SSO implementations. In any SSO
> > > > infrastructure, not just SAML, you should never capture the password
> > from
> > > > the user, store it, and pass it on to other resources. Instead, you
> > > > authenticate the user and generate a token that validates the user,
> > then
> > > > pass the token around to resources that trust that token, such as
> > Google.
>
> > > > If you don't want to create your own SSO infrastructure, you can use
> > an
> > > > existing SSO implementation such as CAS (
> >http://www.ja-sig.org/products/cas/)
> > > > that is known to integrate with Google (and dozens of other
> > applications),
> > > > is stable, secure, free (open-source), and very customizable. Oh, and
> > if it
> > > > doesn't integrate with your application, and you can modify it's login
> > > > process, you can integrated it with CAS yourself.
>
> > > > -Ryan
>
> > > > On Dec 23, 2007 11:55 AM, ByteCode <[EMAIL PROTECTED]> wrote:
>
> > > > > HI,
> > > > > i have a question regarding sso , how does google know that the user
> > > > > has a valid password? cuz i dont see any password submitted back to
> > > > > google in saml response, in other words i may create a Login method
> > > > > which always return the username which means the users is
> > sucessfully
> > > > > authenticated and anyone can login by just typing their username on
> > my
> > > > > sso page?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Apps APIs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-apps-apis?hl=en
-~----------~----~----~----~------~----~------~--~---
